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VIEWPOINT 

The life cycle 


It has been observed that since 
UNIX now has a fair amount of 
market momentum, it must be 
well past its prime technically. 
Common wisdom, after all, holds 
that public acceptance and heavy 
press coverage are the surest 
signs of obsolescence. 

Given this perspective, howev¬ 
er, it’s difficult to assess the role 
UNIX might have in the scientific 
community. Scientists certainly 
would not be quick to say that the 
system’s best years are behind it. 
They know that if UNIX is to 
make a significant contribution 
in their field, it will need to 
achieve a much greater penetra¬ 
tion than it currently enjoys. 

This, of course, has given rise 
to the question: is UNIX, in fact, 
suitable? The logic in this is good, 
but the question is bad. For the 
last 15 years, UNIX has won 
hearts and minds in almost every 
other realm by virtue of its porta¬ 
bility and flexibility. Only the 
most facile mind can imagine the 
array of esoteric UNIX adapta¬ 
tions already in use. The system 
has survived as long as it has 
largely because of its ready accep¬ 
tance of change. 

So we return to the question: 
can UNIX be adapted for scientific 
use? Yes, of course—but prob¬ 
ably not without a price. The 
questions that demand answers 
are: what cost-effective adapta¬ 
tions might be made and how 
might UNIX offer solutions that 
are better than those already 
available to scientists? 

This last question is especially 
intriguing since it takes inertia 
into account. Scientists, like peo¬ 
ple in other professions, have a 
vested interest in the status quo. 
Apart from explorers with mas¬ 
ochistic tendencies, most people 
shun the pain of transition un¬ 
less they can be assured that 
the grass is definitely greener 
on the other side—substantially 
greener, in fact. 


UNIX has yet to demonstrate to 
scientists that its solutions are 
that much better than the ones 
offered by VMS. Indeed, some in 
the scientific community ques¬ 
tion whether UNIX is better at all. 
At the root of this doubt lies the 
Fortran question—a matter that 
Lawrence Berkeley Lab’s Joe 
Sventek wrestles with in the lead 
article of this issue. 

Bob Goff follows with an ac¬ 
count detailing some of the data 
analysis strengths brought to 
bear by UNIX. As a researcher 
who has spent much of his life 
manipulating seismic data, Goff 
speaks from experience. 

The tools offered by UNIX are 
yet another lure deserving atten¬ 
tion. One tool in particular, the S 
system, was specifically designed 
for data analysis. Rick Becker 
and John Chambers, the gentle¬ 
men responsible for the system’s 
development, describe it and dis¬ 
cuss how UNIX influenced this 
design. 

The issue then forges into a 
bugaboo topic—real time. Some 
critics say UNIX can’t handle 
real-time applications effectively. 
Clem Cole of MASSCOMP disa¬ 
grees, and he offers seven good 
reasons why. 

The theme closes with an in¬ 
terview of Steve Wallach, the 
man who helped generate the 
“Crayette” wave with his design 
of the Convex C-l. If Wallach’s 
name sounds especially familiar, 
it’s probably because you’ve read 
about him in The Soul of a New 
Machine. The questions he ad¬ 
dresses come from Rob Warnock, 
himself a systems architect. 

If all this seems to suggest that 
adventures still lie ahead for 
UNIX, so be it. In the scientific 
realm at least, UNIX still has 
many frontiers left to cross. 


(jtr 
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THE MONTHLY 
REPORT 


No simple answers 

by David Chandler 


Two friends were chatting one 
day. One, a casual fellow with a 
penchant for keeping things sim¬ 
ple, was commenting on the oth¬ 
er’s verbosity. “Richard”, he 
said, “you’re always launching 
into some diatribe when all I want 
is a simple response. Can’t you 
ever give me a straight answer?” 
To this the friend replied, “Well, 
yes and no. Let me explain. ...” 

As mentioned in last month’s 
Report , AT&T and Sun Microsys¬ 
tems, Inc., announced in Septem¬ 
ber a major technology-sharing 
agreement whereby technical re¬ 
presentatives from both compan¬ 
ies will work together “to facili¬ 
tate convergence” of System V 
and the 4.2BSD-based Sun OS. At 
first glance, the agreement seems 
to hold great potential for contrib¬ 
uting to the evolution of UNIX as a 
computer industry standard. Fur¬ 
ther study, however, reveals that 
there are certain portions of the 
announcement which are quite 
significant, and certain others 
which are less so. While working 
to avoid verbosity, an explanation 
is in order. 

There was commotion in the 
UNIX community when the an¬ 
nouncement was first made— 
and for good reason. Perhaps the 
greatest excitement was felt by 
those who wish for UNIX to 
become the official standard that 
many say it already is unofficial¬ 
ly. Industry watchers thus were 



stirred when UNIX giants AT&T 
and Sun signed an agreement. 
Add to this the opening line of the 
fact sheet Sun distributed along 
with its press release: “Sun and 
AT&T have agreed to work togeth¬ 
er to converge the two major UNIX 
standards into a single version.” 
Further fanning of the flames 
came from the industry press, as 
evidenced by the front page story 
in Computerworld that cried out, 
“AT&T, Sun to Redo UNIX”. Such 
stories may not be as racy as 
amendments to the Ten Com¬ 
mandments, but they do raise 
eyebrows. 

The facts as presented in the 
announcement of the agreement 
are these: Sun and AT&T will 
incorporate a “reasonable super¬ 
set” of both System V and Sun OS 
into a single, AT&T-endorsed, en¬ 
hanced version of System V. The 
resulting package will be avail¬ 


able from both companies—Sun 
will offer an implementation of 
the common interface on Sun 
workstations (by summer 1986), 
and AT&T will license it in a 
future enhanced version of Sys¬ 
tem V. (Estimates from Sun hold 
that the process at AT&T may 
take as long as two years.) The 
new system will continue to run 
the existing base of System V 
applications and will provide the 
networking services that pre¬ 
viously have been available only 
in 4.2BSD systems. (All of this, of 
course, supports Bruce Borden’s 
thesis that, “The way a standard 
develops is from the implementa¬ 
tion backward as opposed to the 
definition forward.” Borden, the 
manager of engineering at Silicon 
Graphics, Inc., should know— 
he’s been in the UNIX game since 
the Edition 4 days.) 

Presenting this information, 
however, raises more questions 
than it answers. What will the 
Sun-AT&T convergence include? 
What will it exclude? Which com¬ 
pany will contribute what? AT&T 
and Sun are known for having 
different views on networking 
—what does this agreement say 
about that? 

The first two questions—what 
will and won’t be included in the 
system—are loaded ones, and 
company sources decline to be 
specific in responding. This indi¬ 
cates either that they are (under- 
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standably) protective of particu¬ 
lar innovations to be announced 
later, or that such matters have 
yet to be decided, or both. 

According to Laurence Brown, 
supervisor of UNIX Networking 
Systems Engineering at AT&T 
Bell Labs, “All that’s been agreed 
to so far is that we will work 
together to ensure that there is a 
single UNIX standard that will 
both support current System V 
applications and will provide the 
networking services that tradi¬ 
tionally have been offered on 
Berkeley-based systems.” Now, 
System V, of course, already 
“supports current System V ap¬ 
plications”. Does this mean that 
the agreement essentially re¬ 
quires nothing more than the 
grafting of BSD networking facili¬ 
ties onto System V? Indications 
suggest that the process is some¬ 
what more involved. 

For its part, Sun’s first step 
will be to add complete compati¬ 
bility with AT&T’s System V 
Interface Definition (SVID) to the 
Sun OS. While it is significant 
that another major UNIX vendor 
is making this move, it’s not now 
considered news. Bill Joy, vice 
president for research and devel¬ 
opment at Sun, stated at the 
UniForum conference in Dallas 
last January that Sun would 
commit to SVID. Sun will port its 
Network File System (NFS) to 
System V, maintain 4.2BSD fea¬ 
tures and Sun enhancements, 
and incorporate 4.3 enhance¬ 
ments next Spring, but it’s con¬ 
ceivable that Sun might have 
done these things even without 
the agreement with AT&T. 

The new package is not to be a 
“dual” or “layered” port. In the 
Sun System V facility, system 
calls and other facilities required 
for System V are implemented as 
“native” extensions to the Sun 
OS kernel. A separate library is 
used for commands and utilities 
unique to System V. 


Perhaps even more interesting 
than Sun’s actions is the question 
of what AT&T will do. Since the 
focus of the agreement, as Brown 
stated, is on support for System V 
applications and the availability 
of networking services, and since 
AT&T is already very much en¬ 
gaged in the business of support¬ 
ing System V, a major AT&T 
emphasis no doubt will be placed 
on networking. Brown observes: 
“The root of this agreement is 
that both companies feel applica¬ 
tions are important—important 
to maintain compatibility for ex¬ 
isting applications as our individ¬ 
ual systems evolve; and that there 
is important new functionality 
coming in networking, and that 
it’s important to define UNIX 
standards there. AT&T and Sun 
will work on those together as 
part of this agreement. ... We saw 
networking as an area of poten¬ 
tial divergence, and we’d like to 
bring everybody together there.” 

The fact that networking is a 
key issue in the agreement is 
public knowledge. What is not yet 
public are the specific facilities 
the companies will use in their 
joint networking scheme. “Now, 
the exact technology that’s used 
to provide those additional [net¬ 
working] services still needs to be 
worked out”, Brown said, “and 
that isn’t covered by the press 
release. ... We need to agree on a 
common set of networking ser¬ 
vices that will be provided on all 
standard UNIX systems, and then 
any vendor, [in providing] upward 
compatibility for its customers, 
may extend beyond that and offer 
additional features on its sys¬ 
tems.” 

This last remark leads to con¬ 
siderations of how AT&T’s funda¬ 
mental document, the SVID, may 
be altered by the Sun-AT&T 
agreement. Writing in the Febru¬ 
ary, 1985, issue of UNIX REVIEW, 
Doug Kevorkian, supervisor of 
UNIX System Architecture and 
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Operating System Engineering at 
AT&T Bell Labs, stated, “In defin¬ 
ing the relationship between Sys¬ 
tem V and application programs, 
the SVID describes a minimum 
set of system calls and library 
routines that should be common 
to all operating systems based on 
System V. The remaining com¬ 
mands and utilities have been 
grouped into a logical series of 
optional extensions to the base 
definition.” 

The intent of the Sun-AT&T 
agreement is to incorporate BSD- 
derivative networking features 
into the SVID. Does this then 
mean that AT&T will adopt Sun’s 
NFS? Sun’s Bill Joy responded, 
“What has been announced so 
far is that [Sun] will supply an 
NFS for System V, and that NFS 
will be supportable under the 
AT&T networking scheme; in oth¬ 
er words, whatever scheme AT&T 
has for supporting distributed file 
systems will support NFS. There 
hasn’t been any announcement 
[yet] as to what AT&T’s network¬ 
ing options for its customers will 
be.” That is, Sun may or may not 
be sure how, but, as Joy added, 
“Half the code in our system is 
networking, so that has to get 
worked into the common frame¬ 
work somehow.” 

In seeking to determine what 
points are significant in the an¬ 
nouncement of this agreement, 
representatives from all sides fo¬ 
cus on the pivotal role of the 
SVID. This will determine how 
UNIX appears to the end user and 
the application; the technical ma¬ 
nipulations that go on behind the 
interface are of secondary impor¬ 
tance when one speaks of stan¬ 
dards. Bernard Lacroute, execu¬ 
tive vice president and general 
manager of Sun’s workstation 
division, emphasized this point: 
“Of first and foremost impor¬ 
tance is that, at the application 
level, a System V application or a 
4.2 application can run without 


knowing whether or not it’s Sys¬ 
tem V or 4.2.” 

What of significance then 
comes from the announcement of 
the Sun-AT&T agreement? First, 
Sun will support the SVID. Sec¬ 
ond, System V will continue to 
support current System V appli¬ 
cations, while being modified to 
provide BSD-derived networking 
services, the specifics of which 
will be announced later as the 
Sun-AT&T relationship matures. 
The news, then, is not that “The 
Standard Is Here”, but rather 
that ‘ ‘another step in the continu¬ 
ing evolution of the standard is 
here”. 

There is a third point of sub¬ 
stance, or perhaps it should be 
said, “potential substance”. A 
popular computer industry per¬ 
ception holds that UNIX cannot 
be a standard because so many 
versions of it exist. AT&T, how¬ 
ever, has a different perspec¬ 
tive—one that claims the SVID is 
the standard UNIX base from 
which other vendors can add 
features. These features may give 
each version a different flavor, 
but the UNIX system at the base 
will remain standard. If this Sun- 
AT&T agreement contributes to 
the industry’s adoption of AT&T’s 
perspective, it will be substantive 
for that alone. “That is certainly 
our intention”, said Bob Mitze, 
the department head of UNIX 
Computer System Development 
at AT&T Bell Labs. “That is our 
expectation—that. . .people will 
find that by writing to the SVID 
they can write portable programs 
that will move from machine to 
machine. We expect we will be 
able to solidify the standard to the 
point where we won’t find our¬ 
selves with [the] perception [that 
the various UNIX versions are too 
disparate to be one standard]. 
Most programs turn out to be 
fairly easy to port. . . But the 
perception is nonetheless quite 
important, because that has a lot 
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to do with how many people are 
going to write software. . . . The 
market frequently seems to be 
based on perception.” 

ENCORE TAKES A BOW 

A much-anticipated official an¬ 


nouncement from Encore Com¬ 
puter Corp. has finally come to 
pass. Three new product lines 
and a version of UNIX are avail¬ 
able as of this month: a family 
of general-purpose superminis; 
three models of interactive work¬ 


stations; two models of a network 
communication computer (the 
“Annex”); and UMAX, yet an¬ 
other UNIX flavor. 

The Multimax is designed to 
permit up to 20 main processors 
to share a common memory. Con¬ 
figurations cover a broad range of 
capabilities; performance that 
spans 1.5 to 15 MIPS; memory 
capacity ranging from 4 to 32 MB; 
and systems containing from one 
to 10 I/O channels. System prices 
begin at $112,000 for a dual 
processor (1.5 MIPS) system with 
4 MB of shared memory, one I/O 
channel, one 515 MB disk drive, 
one 6250 bpi half-inch tape drive, 
and a workstation display or 
console printer. A large system 
with the same peripherals confi¬ 
gured for parallel processing ap¬ 
plications, with 20 processors (15 
MIPS) and 32 MB of memory, is 
priced at $340,000. The Multi¬ 
max superminis are aimed at the 
general-purpose computer mar¬ 
ket, and so compete with DEC 
VAXen and the Data General and 
Prime machines in this range. 

Although the two low-end mod¬ 
els in Encore’s HostStation line 
of workstations—the 100 and 
110—are single-processor ma¬ 
chines, they are upgradable to the 
top-of-the-line 550, a desktop box 
with two 32-bit processors and a 
base package including high reso¬ 
lution (1056 by 864) 19-inch 
monochrome display, 1 MB of 
memory, 41 MB of internal hard 
disk storage (expandable to over 
370 MB), three RS-232 ports; and 
a 814,000 price tag. 

The Multimax family runs un¬ 
der UMAX 4.2, Encore’s version 
of UNIX offering the full function¬ 
ality of 4.2BSD. UMAX also offers 
parallel and distributed process¬ 
ing extensions, using thousands 
of hardware and software locks to 
protect individual elements with¬ 
in system tables. The system 
features “multithreading”, a de¬ 
sign providing simultaneous ac- 



“Now we can build multi-user 
applications with a relational 
database—without the time 
and expense of programming. 


THAT'S 
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Steve Stone. S.B. Stone & Company, Cleveland. OH 
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If you want to save money and time on application development, call 
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tion and Conference, and while 
Gloria gratefully did not live up 
to dire predictions, UNIX Expo 
seems to have met its objectives 
and then some. 

Held this year at the New York 
Hilton in Rockefeller Center, 
UNIX Expo is a business-oriented 
show, seeking not only to bring 
UNIX people together, but to as¬ 
sist UNIX companies in contact¬ 
ing potential customers: small 
companies, DP/MIS personnel in 
larger companies, VARs—any 
people or organizations consider¬ 
ing the purchase of UNIX sys¬ 
tems. Don Berey, account execu¬ 
tive of show sponsor National 
Expositions Co., Inc., said those 
who came saw what they were 
hoping for: the event boasted 120 
exhibitors and 10,460 attendees. 


The various conferences (four 
tracks covering UNIX and Office 
Automation, UNIX in a Data Pro¬ 
cessing Environment, UNIX Busi¬ 
ness Solutions, and UNIX and 
PCs) “played to standing-room- 
only crowds”, and the tutorials, 
designed and developed by AT&T 
specifically for the show, each 
operated with attendance “at or 
near capacity”. 

Berey also pointed out that a 
large number of exhibitors have 
already reserved space for next 
year’s Expo, to be held again in 
New York City, this time at the 
new Jacob Javits Convention 
Center, October 20-22. 


David Chandler is the Associate 
Editor of UNIX REVIEW. ■ 
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THE HUMAN 
FACTOR 


Of megaflops and multiprocessors 

by Richard Morin 


As noted in a previous column 
(January, 1985), scientists tend 
to have voracious appetites for 
computing power. This, along 
with their tolerance for new and 
unusual ideas, makes them good 
prospects for exploratory com¬ 
puter architectures. Consequent¬ 
ly, many firms with unusual 
hardware designs select the sci¬ 
entific marketplace as their first 
target. Unfortunately, this has 
often consigned scientific users to 
peculiar and even barbaric ex¬ 
cuses for operating systems. The 
scientists, needing lots of mega¬ 
flops, haven’t been able to be 
choosy. 

A new day has dawned, howev¬ 
er, and UNIX is coming to the 
rescue. Simply by being available, 
adaptable, and competently de¬ 
signed, it has become the operat¬ 
ing system of choice for the 
current breed of offbeat scientific 
number crunchers. The fact that 
it has a significant following of 
users and vendors doesn’t hurt 
either. Manufacturers are freed to 
produce just number crunchers, 
knowing that a wide range of 
workstations and other support¬ 
ing components will be available 
from other vendors. Consequent¬ 
ly, we see a host of vector proces¬ 
sors, multiprocessors, RISCs (re¬ 
duced instruction set computer), 
and other machines showing up 
at UNIX trade shows. 

The fight isn’t over, of course, 



and a number of non-UNIX ma¬ 
chines still are being developed. 
Some of these come from old-line 
manufacturers whose existing 
operating systems are quite satis¬ 
factory, at least to their current 
customers. Others, such as data¬ 
flow machines, reduction ma¬ 
chines, and inference engines, 
are so peculiar as to make tradi¬ 
tional operating systems such as 
UNIX entirely unsuitable. Still, 
the facta large number of vendors 
have chosen to base all or part of 
their new ventures on UNIX is 
suggestive of a strong trend. 

Before beginning our survey, a 
few words of warning may be in 
order. First, different architec¬ 
tures are optimized for different 
purposes, and a given machine 
may be entirely unsuitable for a 
given purpose, despite glowing 
performance figures. A vector 


machine that performs very well 
on large array calculations may 
be very poor at monte carlo analy¬ 
sis. Second, benchmark figures 
are always somewhat suspect, 
and published performance rat¬ 
ings are often chosen to favor a 
vendor’s product. Thus, the fig¬ 
ures offered here are more indica¬ 
tive than definitive. Finally, if real 
money is to be spent, a purchaser 
is well advised to investigate the 
track records of the models and 
vendors in question. Buying a low 
serial number product can occa¬ 
sionally be an all too interesting 
experience. 

THE HIGH END 

It's lonely at the top. Only a few 
companies are involved in the 
supercomputer game, and their 
customers—if few—are wealthy. 
Addressing hundreds of mega¬ 
bytes of RAM, and performing 
hundreds of millions of instruc¬ 
tions per second, these machines 
are very powerful indeed. Some of 
the traditional players are still 
around, but a number of new 
companies have also arrived on 
the scene. 

Cray Research (with headquar¬ 
ters in Mendota Heights, MN), 
inspired by hardware guru Sey¬ 
mour Cray, is the premier Ameri¬ 
can producer of scientific su¬ 
percomputers. Cray’s 64-bit ma¬ 
chines, optimized for fast floating 
point calculations and array ma- 
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nipulations, are the standard 
of comparison for scientific num¬ 
ber crunchers. A Cray X-MP, 
for example, can do about 250 
megaflops (250,000,000 floating 
operations per second), for a mere 
$5 million. The Cray 2 is reputed 
to be faster still. And, naturally, 
Seymour is hard at work on the 
Cray 3. But what about software? 
COS, similar to CDC’s NOS, has 
been Cray’s historical proprietary 
operating system, but that pic¬ 
ture has changed. Cray Research 
is using UNIX System V on the 
Cray 2, and says that it will port 
UNIX to the other models in the 
near future. 

Some Japanese firms (Fujitsu, 
Hitachi, NEC) have produced very 
respectable supercomputers. A 


lack of software, among other 
things, has kept these machines 
from being distributed effectively 
outside of Japan. This is in the 
process of changing, however, 
and UNIX is playing a large role. 
All of these vendors have an¬ 
nounced computers that run 
UNIX. In addition, the powerful 
Japanese Ministry of Internation¬ 
al Trade and Industry (MITI) has 
opted for UNIX as its primary 
standard. It is thus only a matter 
of time before UNIX-based super¬ 
computers begin to arrive from 
Japan. 

Denelcor (Aurora, CO) has not 
yet produced a machine that can 
take on a Cray, but it expects to do 
so in the near future. Currently, 
the firm produces only the HEP1 


system, composed of up to eight 
processors, each of which can do 
16 MIPS. Previously plagued by a 
lack of good support software, 
Denelcor has recently announced 
the introduction of a real-time, 
parallel processing version of 
UNIX for the HEP1. The HEP2, 
now being prototyped, is expected 
to be capable of 12K MIPS, put¬ 
ting it firmly in the supercom¬ 
puter league. 

ETA Systems (St. Paul, MN), a 
CDC spinoff, is scheduled to deliv¬ 
er its first ETA-10 UNIX-based, 
vector multiprocessor in late 
1986. Delivering performance in 
the range of 10 gigaflops, the 
system will be able to support 
eight 64-bit vector processors, 
each with up to 32 MB of memory. 
In addition, the ETA-10 can have 
up to 2 GB of shared memory. 

Though commercial supercom¬ 
puters are generally not well 
optimized for scientific tasks, 
their powerful processing and I/O 
capabilities can occasionally be 
very useful. With the addition of 
attached array processors such 
as those made by Floating Point 
Systems (Beaverton, OR), a tra¬ 
ditional commercial mainframe 
such as an IBM 3084 can easily 
qualify for scientific supercom¬ 
puter status. IBM’s interest in 
UNIX has been tepid to date, 
however, and its future directions 
are quite unclear. Still, IBM has 
(grudgingly) announced support 
for UNIX on its mainframe com¬ 
puters. Amdahl (Sunnyvale, CA) 
is also a name to be reckoned with 
in the commercial supercomputer 
field, and it has been a UNIX 
advocate for some years now. 

Finally, any number of super¬ 
computer designs are always 
brewing in assorted laboratories 
and universities. Many of these 
will never be built, and most will 
be of only academic interest. Still, 
it is this ferment that has pro¬ 
duced many of today’s hot ma¬ 
chines, and it will no doubt 
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continue to be a fertile source of 
new computer architectures. The 
ACM SIGARCH newsletters and 
conference proceedings contain 
many interesting descriptions of 
novel theoretical, experimental, 
and even commercially produced 
architectures. Electronics maga¬ 
zine is also a very good source for 
information on new commercially 
produced machines and interest¬ 
ing hardware trends. 

CRAYETTES 

It occasionally happens that 
one's processing requirements 
are not matched by a budget 
allowing the purchase of a multi¬ 
million dollar number cruncher. 
This could happen to anyone, but 
fortunately there are several ven- 


These are exciting 
times for hardware 
junkies, and UNIX 
continues in its role as a 
distributed laboratory 
for computer science 
research. 


dors who are quite eager to help. 
The machines they produce, 
known as Crayettes, typically 


cost less than a megabuck, but 
provide as much as a quarter of 
the power of a Cray. Many of these 
machines are augmented by an 
assortment of vectorizing compil¬ 
ers and other software aids. 

Several Crayette producers are 
making full vector processors. 
Two such machines, aimed di¬ 
rectly at Cray owners, are pro¬ 
duced by American Super Com¬ 
puter and Scientific Computer 
Systems. These companies have 
chosen to maintain binary com¬ 
patibility with Cray 1 processors, 
and are even porting Cray’s COS. 
This strategy may be short-lived, 
however, in light of Cray’s move 
to UNIX. A number of other 
vendors have decided to go with 
UNIX, occasionally assisted by an 
underlying parallel kernel. 

Alliant Computer Systems (Ac¬ 
ton, MA) makes a multiprocessor 
4.2BSD system that supports up 
to 256 MB of real memory, 2 GB of 
virtual memory, and a mixture of 
computational and interactive 
processors. At its full configu¬ 
ration of eight 32-bit vector pro¬ 
cessing computational elements, 
the system can reach speeds of 94 
megaflops and 35 MIPS. The 
Alliant Fortran compiler auto¬ 
matically detects opportunities 
for parallel execution, allow¬ 
ing the runtime environment to 
perform entire DO loop bodies 
on multiple processors. Special 
hardware and software allow the 
system to deal with dependencies 
of one iteration on another. 

Convex Computer Corp. (Rich¬ 
ardson, TX) produces the C-l 64- 
bit pipelined vector processing 
system, which runs an operating 
system based on 4.2BSD. The C-1 
is able to do 60 megaflops and 
handle up to 128 MB of memory, 
while maintaining VAX/VMS For¬ 
tran compatibility. An interesting 
technique known as “disk strip¬ 
ing’’ is now being used by Convex. 
With this technique, a set of disk 
drives is treated as a single drive. 


Great-looking TROFF output 
from low-cost laser printer! 

■ Now! Full support for LaserJet+B 

For several years, Textware has been licensing TPLUSt software to process 
the output of troff and ditroff for a wide variety of phototypesetters, laser 
printers, etc. Now, with TPLUS driving the LaserJet*, we have again set a new 
standard for price/pcrformance. By adding our Graphics Option , with DWBt, you 
have the total solution to your document production requirements. 

Many organizations are now getting maximum benefit from the HP LaserJet, 
using our TPLUS/LJ software. The low-cost LaserJet is a remarkable value on 
its own—8 page per minute output speed, 300 dot per inch resolution, and 
typesetter-quality fonts. TPLUS gives you access to all 
this and more from your own system. We support all the 
characters and accents needed by troff and eqn; in 
addition, special characters (©; logos too) can be sup¬ 
plied or generated to meet specific requirements. Our 
precise handling of rules and boxes allows you to take 
full advantage of tbl for forms, charts, etc. 

While even LaserJet output is not in the same class as the best phototype, it is 
certainly well suited to documentation and a broad range of other applications. 
When you do have a need for phototypeset images, TPLUS and the LaserJet will 
save you time and money. Preview mode lets you proof all aspects of your docu¬ 
ments conveniently, in-house, before sending out for phototypesetting (from our 
UNI#TEXT service). Cross-device proofing is a standard feature of TPLUS. 

The HP LaserJet printer is not only inexpensive—it is an exceptional value! 
Want proof? This entire ad was set in position using TPLUS on the LaserJet! 

t TPLUS is a trademark of Textware Inti. t Documenter’s Workbench is a trademark of AT&T 

For further information, please write or call. 

Also available for: 

• AM 5810/5900 & 6400, APS 5 & ^ 5 , 

CG 8400 & 8600, Mergenthaler 202 

• Xerox 4045, 2700/3700 & 8700/9700 

• BBN, Sun, 5620 & ‘PC’ CRTs 

• Diablo, Qume & NEC LQPs 

• C Itoh & Epson dot-matrix 
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EQN examples 

lim (tan * ) ,in 21 = 1 

X —*7f/2 

a+fi 

n e Sk ‘ k/k 

k> 1 

sin(x) 
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Unix is a crai iemark of AT&T Bell Laboratories. MS-DOS and Xenix are trademarks of Microsoft Corp. CP/M is a registered trademark of Digital Research Inc. 
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V THE HUMAN FACTOR 


Concurrent writing allows data 
transfer rates to be multiplied, 
and the increased apparent size 
of the disk allows much larger 
files to be handled. 

Other vendors have opted sim¬ 
ply to produce fast multiprocessor 
scalar machines. The most ag¬ 
gressive design of this sort comes 
from Flexible Computer (Dallas, 
TX), whose FLEX/32 can com¬ 
bine up to 20,840 processor 
cards, currently based on the 32- 
bit NS32032 microprocessor. A 
key design factor, however, is the 
system’s ability to integrate many 
different kinds of processing ele¬ 
ments. Supporting real-time as 
well as number crunching appli¬ 
cations, the system allows both 
hardware and software reconfi¬ 


guration to be done while the 
system is running. 

ELXSI (San Jose, CA), another 
multiprocessor vendor, has cho¬ 
sen instead to use small numbers 
of very powerful processors. The 
ELXSI product is perhaps more of 
a parallel mainframe than a mini¬ 
supercomputer. Its 300 MB-per- 
second bus supports up to twelve 
64-bit processors, each of which 
is approximately equivalent in 
power to a DEC VAX 8600. The 
processors can share 200 MB of 
memory, to be quadrupled with 
the introduction of 256 kilobit 
RAM chips. A company spokes¬ 
man notes that parallelization of 
code is often far easier than 
vectorization, and that such pro¬ 
grams as SPICE are easily and 


efficiently run on ELXSI archi¬ 
tecture. 

In its newly announced iPSC 
system, Intel Scientific Comput¬ 
ers (Beaverton, OR) has opted to 
use CalTech’s hypercube archi¬ 
tecture. In this design, 2 N process¬ 
ing nodes are used, with each 
node being able to communicate 
directly with N other nodes. The 
iPSC can be purchased in con¬ 
figurations of 32, 64, or 128 
nodes, with each node containing 
an 80286 CPU, an 80287 FPU, 
and 512 KB of memory. The 
system is controlled by a UNIX- 
based “cube manager’’, which is 
responsible for resource manage¬ 
ment, user interface, and other 
support functions. At 25 to 100 
MIPS and 2 to 8 megaflops, the 
iPSC is hardly a full supercom¬ 
puter, but at $500,000, it does 
provide a relatively economical 
base for research into arbitrary 
multiprocessor topologies. 

Literally dozens of vendors are 
producing multiprocessor or oth¬ 
erwise unusual UNIX systems. 
February’s UniForum trade show 
in Anaheim will no doubt be full 
of such vendors hawking their 
wares, with the offbeat systems 
standing next to the YAWN (Yet 
Another Workstation or Network) 
products. These are exciting 
times for hardware junkies, and 
UNIX continues in its role as a 
distributed laboratory for com¬ 
puter science research. 

Mail for Mr. Morin can be 
addressed to Canta Forda Com¬ 
puter Lab, PO Box 1488, Paci¬ 
fica, CA 94044. 


Richard Morin is an independent 
computer consultant specializing 
in the design, development, and 
documentation of software for engi¬ 
neering, scientific, and operating 
systems applications. He operates 
Canta Forda Computer Lab in Paci¬ 
fica, CA. ■ 
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UNIX* COMMUNICATIONS 

X.25 • HASP • SNA3270 • SNA3770 

Drop-in communication systems for MULTIBUS* based 
computers. Offload the CPU intensive process of com¬ 
munication with the HORIZON"™ Series of boards from 
MORNING STAR. Complete systems include your choice of 
hardware and software combinations to custom fit your 
data communication needs. Available for: Sun 
Microsystems, Masscomp, Pyramid, Heurikon, Plexus, 
NCR Tower, Sperry 5000, Celerity and more. 


Call today for more information 



Morning Star Technologies, Inc. 

1760 Zollinger Road, Columbus, Ohio 43221 

In Ohio call [6ia] 451-1883 TWX - 510 - BOO - 32*72 

•UNIX is a Trademark of ATST Bell Labs • MULTIBUS is a Trademark of Intel Corp 

Circle No. 292 on Inquiry Card 


22 UNIX REVIEW NOVEMBER 1985 






















le on the cutting 
computers. 

omputersys- 


The Firebreathers continu 
edge of high performance 

The most powerful line of 
terns made. Gould 
PowerNodes'" and 
CONCEPT/32s" 

Any way you 
slice it they beat 
the VAX'" 

Our main¬ 
frame PN9000 and 
CONCEPT 32/97 

are up to twice as fast as the K/AX 8600. 

And even though the mic -range 
PN6000 and CONCEPT 32/C 7 are 30-50% 
smaller than the VAX 11/780, they're still up 
to three times more powerful 

More power for a slice of the price. 
Despite their superior power, our mid¬ 


range models cost 40% less than the VAX 
11/780. Our mainframes cost about 30% 
less than the new VAX 8600. The bottom 
line is more power for less money. 

Operating environments that are a cut 
above the rest. 

There’s also a choice of system soft¬ 
ware to consider. Gould’s unique UTX/32® 
is the first operating system to combine 
UNIX* System V with Berkeley BSD 4.2. So 
it allows you to access virtually any com¬ 
mand format you want whenever you want. 

And in real-time environments, Gould's 
MPX/32'” operating system offers perfor¬ 
mance that's unmatched in the industry, 
as well. 

Delivery that’s right on the mark. 

Unlike the VAX &600, that has up 
to a 12 month wait for delivery, when you 


order either a Gould PowerNode or a 
CONCEPT/32 system, they’ll be shipped 
within 90 days ARO. 

You can also be sure with Gould you’re 
getting a computer that’s backed by years 
of experience- the kind of experience we 
used to develop the first 32-bit real-time 
computer. 

If you need more information or just 
have a few questions, give us a call at 
1-800-327-9716. 

See for yourself why VAX no longer 
cuts it. Go with a Gould computer and ax 
the VAX. 

CONCEPT/32 and UTX/32 are registered trademarks and PowerNode 
and MPX/32 are trademarks of Gould Inc. VAX is a trademark of Digital 
Equipment Corp UNIX is a trademark of AT&T Bell Labs 

■> GOULD 


IV Gould computers have a 
big enough edge/to ax the\4AX. 
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UNIX and scientific applications: symbiosis or antithesis? 

by Joseph S. Sventek 


The popularity UNIX enjoys in 
many segments of the computing 
community is hardly a secret. 
Historically, it has been the oper¬ 
ating system of choice on mini¬ 
computers in academic circles. Its 
recent availability on supermicro 
computers also has made it an 
attractive system for the business 
community. Even the home com¬ 
puter market has been affected 
by Xenix, PC/IX, and various 
UNIX work-alikes. 

There is, however, one major 
segment of the computational 
fraternity that has received UNIX 
with something less than enthu¬ 
siasm—the scientific communi¬ 
ty. This is not to imply that UNIX 
cannot be applied to scientific 
problems—the remaining arti¬ 
cles in this issue provide evidence 
to the contrary. Even so, there are 
some legitimate reasons for the 
reticence scientists have shown 
in adopting UNIX. This article 
explores those reasons and offers 
a prognosis for the future suc¬ 
cess of UNIX systems in this 
marketplace. 

A TAXONOMY OF 
SCIENTIFIC APPLICATIONS 

The first major category of 
scientific applications might best 
be described as “computationally 
intensive”. These applications 


There is one major 
segment of the 
computational 
fraternity that has 
received UNIX with 
something less than 
enthusiasm—the 
scientific community. 


are of two general types: numeri¬ 
cal simulations of physical phe¬ 
nomena and analysis of experi¬ 
mental data. Applications of 
either type make huge demands 
on a CPU’s ability to perform 
floating point operations (FLOPs). 
The operating system features 
with the biggest impact on the 
execution of these applications 
are unlimited process address 
space and high-level compilers 
capable of generating efficient 
floating point object code. 

The second major category of 
scientific applications is made up 
of event-driven tasks, which can 


be partitioned into data acquisi¬ 
tion systems and experimental 
control systems. Each applica¬ 
tion must be able to respond 
quickly to external events, where 
this quickness depends on the 
system being measured or con¬ 
trolled. The critical services pro¬ 
vided by an operating system in 
support of this category include: 
1) small (or bounded) interrupt 
latency, 2) a user-tailorable prior¬ 
ity scheduler, and 3) non-block¬ 
ing system services accessible to 
user processes. 

One class of applications in 
particular represents a combina¬ 
tion of the “computationally 
intensive” and “event-driven” 
requirements: computer graph¬ 
ics. Graphical summaries of sim¬ 
ulated or analyzed data usual¬ 
ly entail significant amounts 
of floating point computation, 
while real-time displays sup¬ 
porting event-driven applications 
represent additional peripherals 
for which the processing time 
must be bounded. Applications of 
this sort require that the operat¬ 
ing system provide interactive 
display tools and standard graph¬ 
ics library calls for program 
invocation. 

In summary, for a single oper¬ 
ating system to support all major 
categories of scientific applica- 
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tions, it must provide the follow¬ 
ing facilities: 

• unlimited process address space 
(virtual memory). 

• efficient high-level language 
compilers. 

• bounded interrupt latency. 

• priority scheduling. 

• user-mode asynchrony. 

• standard graphics subroutine 
libraries. 

• interactive graphics utilities. 

A SHORT HISTORY OF 
SCIENTIFIC COMPUTING 

Although we are primarily con¬ 
cerned with the relevance of 
UNIX to scientific computation, 
knowledge of the culture that has 
developed in scientific computing 
circles will help us more fully 
understand the situation. It is 
important to note that, after code 
breaking, computationally inten¬ 
sive scientific applications made 
the first major use of early com¬ 
puters. These early programs 
were written in machine lan¬ 
guage. 

As scientific computation grew 
more commonplace, it became 
apparent that the low-level pro¬ 
gramming languages of the day 
(machine and assembly) were 
hampering productivity severe¬ 
ly. In response to this, one of the 
first high-level languages, For¬ 
tran (FORmula TRANslation), 
was designed to permit scientists 
to program in a language closer to 
the algebraic formulas used in 
their initial derivations of prob¬ 
lems. The tremendous improve¬ 
ment provided by Fortran quickly 
led to its adoption as the lingua 
franca of scientific computing in 
the early 1960s. Since most com¬ 
putational resources were quite 
scarce, Fortran compilers devel¬ 
oped a reputation for generating 
very efficient object code. 

One factor that often deter¬ 


mines the envelope of experimen¬ 
tal and theoretical science is the 
amount of computational power 
that can be brought to bear on the 
problems at hand. Other system 
considerations (like the command 
language, the program develop¬ 
ment environment, and the file 
system) are secondary to the 


UNIX, as it is 
commonly delivered, is 
not able to provide the 
facilities necessary to 
support event-driven 
applications. 


number of FLOPs that can be 
performed. As a result, organiza¬ 
tions with an insatiable appetite 
for FLOPs (such as the US Depart¬ 
ment of Energy laboratories) 
tended to order only bare hard¬ 
ware from supercomputer man¬ 
ufacturers in the early days of 
scientific computing. The system 
programming staffs of these orga¬ 
nizations would then craft mini¬ 
mal batch or timesharing operat¬ 
ing systems on top of this iron. 
The highest priority item during 
the development of these operat¬ 
ing systems was always an opti¬ 
mizing Fortran compiler. Other 
aspects of the system were usual¬ 
ly made compatible with previous 
systems—leading to virtual im¬ 
mortality for a number of primi¬ 
tive operating system interfaces. 

As scientists started to become 
involved in event-driven applica¬ 
tions, they naturally wanted to 
use a programming language with 
which they were familiar. As a 
result , local extensions to Fortran 


(both the language and its run¬ 
time library) were implemented to 
permit the language’s use in 
these real-time systems. Such 
local extensions generally caused 
a decrease in the productivity of 
programmers because of the mo¬ 
bility of scientific researchers. 
The fact that these originators 
often were not available for later 
support of their software meant 
that others either had to live with 
the problems they found or had to 
re-write whole sections of code. 
To guard against this, several 
progressive standards were devel¬ 
oped for the Fortran language 
(ANSI X3J3). 

This all has served to make a 
good Fortran compiler essential 
to a scientific computer system. 
The compiler must accept pro¬ 
grams written in standard For¬ 
tran and generate efficient object 
code. Most scientists don’t care 
much about the rest of the sys¬ 
tem, opting for compatibility with 
the past whenever a choice is 
available. 

STANDARD UNIX 
SUPPORT FOR 
SCIENTIFIC APPLICATIONS 

UNIX provides many of the 
facilities necessary to support 
the computationally intensive 
class of scientific applications. In 
particular: 

• With the introduction of 3BSD, 
virtual memory support in UNIX 
systems was established. Berke¬ 
ley has continued to improve the 
virtual memory support in BSD 
releases, while many commer¬ 
cial vendors—AT&T included— 
have begun to offer their own 
support for virtual memory. 

• A Fortran compiler (f77) is pro¬ 
vided. While this compiler cor¬ 
rectly processes standard For¬ 
tran, some of the design de¬ 
cisions in the construction of the 
compiler prevent it from gener¬ 
ating efficient object code. (See 

Continued to page 44 
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RUN 

THROUGH 

THE 

MILL 

Experiences with 
scientific data analysis 
using UNIX 

by Robert Goff 


e 

W^eientific computing is a very 
mixed bag. It seems that scien¬ 
tists are particularly imaginative 
when it comes to devising appli¬ 
cations that find the weaknesses 
in an operating system or hard¬ 
ware configuration. The diver¬ 
sity in functionality required for 
even relatively simple scientific 
data analysis leads to system 
complexity and performance re¬ 
quirements almost unheard of in 
other major segments of the com¬ 
puting industry. It also raises the 
inevitable question: is UNIX real¬ 
ly up to it? 

A complete answer, of course, 
is not possible in the space allo¬ 
cated to this article, nor, for that 
matter, in this entire issue of 
UNIX REVIEW. Rather, what will 
be attempted here is a discussion 
of a few of the adversities await¬ 
ing the scientific system develop¬ 
er and a sampling of problems 
that UNIX has played a key role in 
solving. 

CONVENTIONAL WISDOM 

As in any other discipline, 
much of the “knowledge” sur¬ 
rounding the use of UNIX for 
particular types of applications 


comes in the form of old wives’ 
tales. Most of these tales have 
some basis in fact or history, but 
none should be taken at face 
value without investigating the 
implications for the specific ap¬ 
plication at hand. Many of the 
restrictions that purportedly be¬ 
set UNIX either only apply to a 
restricted set of problems or re¬ 
flect deficiencies that already 
have been solved over the course 
of the operating system’s evolu¬ 
tion. The old unstablefile system 
bugaboo is a classic example of a 
malady that no longer plagues 
UNIX. 

Conventional wisdom says if 
you are trying to acquire even a 
moderate amount of data in real 
time, you shouldn’t use UNIX. 
Everybody knows that UNIX does 
not function well when subjected 
to the high interrupt rates char¬ 
acteristic of this kind of machine 
activity. Either you won’t be able 
to keep up with the incoming data 
or you’ll have to assign the acqui¬ 
sition such a high priority that 
the machine will become slug¬ 
gish, the clock will lose time, the 
disk will blow revs , and the crash 
rate will go up alarmingly. But 
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how much of this is really true? 
And what does it mean to your 
application? 

At the heart of this consider¬ 
ation is the question: what do 
you mean by real time? A simi¬ 
lar, equally perplexing issue is the 
need to come to grips with what a 
development environment is 
and how that differs from a 
production environment. The 
virtues of UNIX in a development 
environment are well known by 
now and no doubt account for a 
large component of the system’s 
popularity in the research com¬ 
munity. After all, the major cost 
component in most development 
projects is people time —a cur¬ 
rency that well displays the value 
of UNIX. But does this mean that 
the system’s value goes down as 
we get closer and closer to freez¬ 
ing the code ? 

In scientific data analysis, a 
similar contrast often is suggest¬ 
ed between off-line and re¬ 
search mode (interactive) pro¬ 
cessing. Does it become nothing 
more than a question of volume, 
or is there something fundamen¬ 
tally different in the way these 
two types of computing are done? 
If a difference is suspected, is it 
borne of convention or necessity? 
Can UNIX support a high volume 
processing environment? Alas, 
there is no universal answer. The 
question that really needs to be 
asked is: what is meant by “high 
volume"? 

REALTIME AND UNIX 

As a simple illustration, I will 
describe a data acquisition sys¬ 
tem now underdevelopment. The 
hardware is a MC68000 Multi¬ 
bus box running 4.2BSD. We in¬ 
tend to acquire approximately 20 
channels of seismic data and 
digitize it at 20 samples per 
second to 16-bit accuracy. The 
sampling operation must be syn¬ 
chronized with coordinated uni¬ 
versal time (UTC) to obtain an 


absolute sample timing uncer¬ 
tainty of less than 20 millisec¬ 
onds. The application also must 
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run in the presence of other 
processes that route the data to 
its final destination over a com¬ 
munications link. 

In view of the relatively low 
data rate and the short time 
allotted for device driver develop¬ 
ment, we chose a simple, inex¬ 
pensive multiplexed analog-to- 
digital converter board offering 
two major programming modes, 
both of which generate an inter- 
rupt-per-sample. In retrospect, it 
probably would have been wiser 
to spend about half again as 
much money on this module to get 
a board with some on-board buf¬ 
fering and a DMA bus interface. 
This was rejected, however, since 
all the boards that we found 
required some custom firmware 
development for an on-board mi¬ 
cro. We simply chose not to devote 
that much time to this aspect of 
the development. 

The device driver for the sys¬ 
tem took about two weeks to write 
and was designed to allow us to 


use the board in any of its pro¬ 
gramming modes with any config¬ 
uration of inputs. We knew that 
at a rate of approximately 400 
interrupts per second, problems 
were likely, so we paid particular 
attention to streamlining the in¬ 
terrupt handler in the hope that 
we might avoid burning system 
time at an inordinate rate. Of 
equal importance was the fact 
that we needed to maintain an 
overall system throughput that 
would allow us to keep up with all 
of the tasks associated with refor¬ 
matting and transmitting the 
data—and would allow us to 
maintain a reasonable set of rec¬ 
ords on the state of the system’s 
health. The upshot is that the 
system had to be designed so that 
it wouldn’t monopolize critical 
system resources unnecessarily. 
This amounted to integrating ac¬ 
quisition tasks into the system in 
a way that was polite to other 
activities. 

We next wrote some user-level 
code to read the data. This is 
where we really started to learn 
how the system would react. The 
first programming mode we tried, 
known as random mode , re¬ 
quired that the interrupt handler 
supply a new channel and re-arm 
the converter trigger for each 
sample. We started experiment¬ 
ing with relatively low trigger 
rates before cranking up the 
speed to see if we could reach our 
goal of an aggregate conversion 
rate of 400 samples per second. 
The actual conversion process 
takes only about .4 milliseconds, 
so we could tolerate interrupt 
service delays of as much as 24.6 
milliseconds before data over¬ 
runs would occur. 

We were somewhat disappoint¬ 
ed to learn that even at a low 100 
sample-per-second rate, we ex¬ 
perienced an unacceptable num¬ 
ber of data overruns—even when 
the machine was unloaded. We 
tried busy/wait loops in place of 
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kernel sleeps and used other 
methods that made the acquisi¬ 
tion less polite bun it quickly 
became clear that we were on the 
wrong track. Without placing the 
hardware interrupt priority of the 
board considerably higher than 
we wanted, we could pee that this 
mechanism was not going to 
work. 

The other programming mode 
that was available to us is called 
scan mode. Under this scheme, a 
trigger is used to initiate an entire 
scan that starts ak some low 
channel number and proceeds to 
some higher channel number. 
The trigger begins tne first con¬ 
version and upon completion, 
issues an interrupt The act of 
reading the data initiates conver¬ 
sion on subsequent Channels un¬ 
til the high channel is reached, at 
which time an end-of-scan is 
signaled and the board stops, 
waiting for the next trigger. Note 
that the sequence involves field¬ 
ing just as many interrupts as 
random mode would require but 
allows the interrupts to be spread 
out in accordion fashion over the 
full time interval allotted for the 
scan. 

In order to use scran mode, we 
knew we would have to give up 
the generality of being able to 
sample the channels in any order. 
We decided, though, that this 
sacrifice was of minor practical 
importance since the data had to 
be massaged before transmission 
if samples were to be rearranged 
with little penalty. Of more con¬ 
cern was the fact that scan mode 
would not allow ms to control 
absolute sample timing as well. 
Conversions became a function of 
how quickly we could get around 
to servicing the interrupts for all 
the earlier channels in a scan. To 
solve this problem] some instru¬ 
mentation was necessary to de¬ 
termine the length pf the average 
scan. If we could get a good 
estimate of the constant portion 


of the delay between the trigger 
and conversion for each channel, 
we felt we could at least remove 

— 2 - 3 — 

The major cost 
component in most 
development projects 
is people time —a 
currency that well 
displays the value of 
UNIX. 


that component of the timing 
error. 

Using scan mode, we found 
that we could speed up the aggre¬ 
gate conversion rate to more than 
1 000 samples per second in the 
presence of other processing be¬ 
fore we experienced any data 
overruns. It should be added that 
the prototype system was con¬ 
nected to other machines at our 
facility via a local area network 
and had no disk of its own. A 
fairly severe test of the system 
came when we inadvertently left 
the rwho daemon running during 
one of our test runs. The rwho 
daemon presents an intermittent 
load to the system and makes 
network traffic, in particular, 
fluctuate wildly. These tests led 
us to another modification of our 
approach. 

We had allowed the interrupt 
handler to place newly arriving 
samples into a buffer (allocated in 
the device driver) that could hold 
about 1 second of incoming data. 
We devised a simple wrap-around 
scheme for handling buffer over¬ 
flows and a sequencing method to 
report them as they occurred. The 


user-level code we were using 
read one scan at a time and 
placed the data on disk files 
(across the network). Only when 
we started to add functionality 
did further problems arise. 

It seemed we just couldn’t 
make the program run fast 
enough (or get enough of the CPU) 
to keep up with the data. The 
application would run for a while 
and sooner or later produce a 
buffer overflow. I suggested that 
we instrument the code until we 
really understood where the bot¬ 
tleneck existed. A few hours later, 
one of the programmers on the 
project mentioned that he’d no¬ 
ticed rwho running while he was 
performing his tests, leading him 
to wonder if this might be the 
source of the trouble. Of course, 
his comment led us right to where 
the real problem had been all 
along—in the device driver’s 
small buffer size. When we ex¬ 
panded this buffer to accommo¬ 
date 8 seconds of data, all prob¬ 
lems of this nature disappeared. 

WHAT ARE THE LESSONS? 

The two solutions illustrated 
above are not terribly surprising 
in and of themselves—in fact 
they are fairly obvious to everyday 
users of UNIX. What is surprising 
(or at least was to me) is the 
magnitude of the effect they por¬ 
tray. I never would have thought 
that we could squeeze a ten-fold 
sampling rate increase out of our 
system simply by easing the criti¬ 
cal path problem presented by the 
interrupt service mechanism. Nor 
would I have dreamed that we 
would have to let our user-level 
code ignore the incoming data 
stream for anything close to 
8 seconds during routine pro¬ 
cessing. 

What this illustrates is that, 
compared to smaller, less func¬ 
tional operating systems, UNIX 
gives the appearance of a higher 
degree of asynchrony in its man- 
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agement of machine activities. 
On the face of it, this may seem to 
be a disadvantage in that system 
buffers need to be larger and 
critical paths may become more 
numerous and difficult to fore¬ 
cast. But, though critical path 
management may be more impor¬ 
tant, the facilities provided by the 
operating system for doing it are 
more numerous and general, and 
the help they provide to the 
system developer may result in 
better overall system throughput 
when the processing load is ana¬ 
lyzed as a whole. 

As the limitations on system 
throughput are explored, it’s in¬ 
variably found that one critical 
resource or another is in short 
supply. Under UNIX, there may be 
a few more procedure calls be¬ 
tween you and the handling of an 
interrupt or the reading of some 
data—and this may affect maxi¬ 
mum system throughput if the 
resource in short supply is CPU 
time—but UNIX also provides 
some tools for use in dealing with 
these problems. 

Without extraordinary effort, 
anything approaching total utili¬ 
zation of all system resources is 
unlikely. So the task faced by the 
system developer is to offload 
processing from resources that 
are approaching saturation to 
those that are under-utilized. 
UNIX helps with these efforts. 

In the final analysis, the re¬ 
source that the system developer 
must manage most carefully is 
development time. After only two 
weeks of development, we had a 
device driver with only one minor 
deficiency—one that was easy to 
remedy. Further, the level of func¬ 
tionality and flexibility we were 
able to achieve in that time was 
significantly improved by the 
completeness and generality of 
the model on which UNIX de¬ 
vice driver implementations are 
based. The availability of facili¬ 
ties such as a general-purpose 


kernel sleep mechanism can be 
invaluable when efficient use of 
critical resources becomes im¬ 
perative. 

Since this application does not 
tax most of the resources pro¬ 
vided by our machine (the CPU in 
particular), it is clear that a 
significant increase in capacity 
should be possible. The job of 
implementing a device driver for a 
higher performance A/D system 
would not, in my estimation, be 
significantly harder or more time 
consuming than for the simple 
device we have used. Further, the 
impact of the acquisition on the 
remainder of a machine’s pro¬ 
cessing load should, if anything, 
be more controllable since the 
device in question should have 
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more intelligence and its fea¬ 
tures should be fairly accessible. 
Thus, custom firmware develop¬ 
ment aside, an attractive expan¬ 
sion path for the system seems to 
exist. In our case at least, this 
owes in part to our choice of UNIX 
to do the job. 

DIFFERENT GOALS, 
DIFFERENT APPROACH 

To show how some of these 
issues stack up in the larger 
scheme of things, I will describe 
another data acquisition system I 
took part in developing. The main 
emphasis of this project was di¬ 
rected toward doing a small 
amount of processing on a large 


volume of data at a minimal 
hardware cost. To accomplish 
this, a PDP-11/23 system run¬ 
ning RSX-11M was chosen for 
the development work, with the 
idea that we would run the pro¬ 
duction system under RT-11 once 
we were done. 

The project involved acquiring 
30 channels of data from a micro- 
wave telemetry link connected to 
a small array of seismic stations 
some 70 miles away. Each chan¬ 
nel was to be sampled at 250 
readings per second, making for 
an aggregate data rate of 7500 
samples per second—one consid¬ 
erably higher than in the previous 
example. The only processing to 
perform, however, consisted of 
demultiplexing and time-stamp¬ 
ing the data before passing buffer 
loads of it to another machine (a 
PDP-11/34), via DMA, for further 
processing. 

Since no off-the-shelf inter¬ 
face was suitable for connection 
to the telemetry, we had to devel¬ 
op our own. We chose to build a 
fairly fancy device for offload¬ 
ing the demultiplexing from the 
11 /23 CPU. This DMA device only 
required that it be told from time 
to time (about once a second) the 
hunk of memory into which it 
needed to poke its data. It then 
signaled the CPU with an inter¬ 
rupt whenever a buffer filled and 
a new address was needed. 

Since disposing of the data also 
was to be done via DMA, most of 
the heavy work could be handled 
by specialized hardware. The 
main tasks for the CPU consisted 
of reading time information from 
a UTC clock, attaching that infor¬ 
mation to buffers as they were 
filling, doling out buffer address¬ 
es as needed, and responding to 
operator requests for system 
monitoring information. 

As it turns out, several things 
slowed the pace of our project, not 
the least of which was our initial 
unfamiliarity with the DEC oper- 
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ating system and hardware. We 
had decided early on that since 
the development of our teleme¬ 
try interface would take a fair 
amount of time, we would have to 
undertake the software develop¬ 
ment in parallel. Ini dal develop¬ 
ment proceeded rather slowly and 
resulted in a system that was far 
from expandable either in capac¬ 
ity or functionality. 

By the time the system finally 
gave in and showed signs of 
working, we had evolved to a 
standalone-system approach for 
the software. This is not to say 
that the operating system we had 
chosen was unsuitable or defi¬ 
cient, but simply that we found 
we were using less and less of its 
facilities as time went by. We 
finally decided that we could do 
without it altogeth er since the 
activities we were trying to man¬ 
age were few in lumber and 
highly synchronous in nature. In 
doing so, we gained considerably 
tighter control over utilization of 
the resources at hand. 

The definition of this system 
was characterized ty fairly tight 
machine constraints, a narrow 
set of goals, and the fact that the 
desired result of our development 
was a black box —a prime candi¬ 
date for cross-develc pment under 
UNIX. After re-writing our early 
assembly language software in C 
(and purchasing a 0 compiler for 
the 1 1 /23), we now have a system 
that can be modified easily and 
yet still boasts the high perfor¬ 
mance/cost ratio we were looking 
for. 

WHAT ABOUT ANALYSIS? 

Scientific data analysis is an¬ 
other class of problems for which 
UNIX has some unique solutions. 
Like people, analysis techniques 
come into the work , grow up, get 
old, and sooner or later die. 
During the early stages of this life 
cycle, a technique’s developers 
will try to ascertain the applica¬ 


bility of their new analysis tool, so 
a fairly rough and unsophisticat¬ 
ed implementation of the idea 
usually will suffice. If a scheme 
proves useful and is allowed to 
continue its growth toward matu¬ 
rity, it will be cloned many times 
and the copies that are sent out 
into society will be molded by 
their environment into tools di¬ 
rected at the specific needs of 
particular projects. As these tech¬ 
niques grow more sophisticated, 
some may be trained toward high¬ 
er and higher degrees of special¬ 
ization. This transformation may 
leave little of the essence from 
which the techniques came. At 
many of the stages along this 
evolutionary path, malleability 
may be the factor that determines 
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whether a particular instantia¬ 
tion will be a candidate for fur¬ 
ther duplication or be discarded 
in favor of a younger sibling. 

A class of techniques impor¬ 
tant to seismologists is derived 
from the realm of signal process¬ 
ing , and is roughly categorized 
as time-series analysis. This 
extended family of processing 
schemes can be sub-categorized 
in various ways, but the building 
blocks include things like dot 
products, vector products, FFTs, 
weighted sums, and matrix multi¬ 
plies. These are the fingers and 
toes of the individual packages. In 
the same way that you can tell 
girls from boys, some people 


think that you can differentiate 
between high-volume production 
packages and research tools. 
Does this distinction mean that 
the parts are never interchange¬ 
able? Given that creative surgery 
is often the genetic engineering 
methodology of choice for soft¬ 
ware developers, we might ask, 
“Can we graft the toe of the 
fullback onto the foot of the 
ballerina and expect good re¬ 
sults? Will we get a female track 
star or end up with a clumsy 
dancer?” 

PARTS IS PARTS 

A key method for increasing 
the predictability of surgery is to 
make processing modules work 
more like spare parts than fingers 
and toes. Over the years, comput¬ 
ing has generated many helpful 
models for the fabrication and 
interconnection of these parts— 
among these are processes, pro¬ 
cedures, libraries, include files, 
and macros. Tools for creation, 
routine maintenance, repair, and 
replacement also abound in lan¬ 
guage compilers, linkers, editors, 
library managers, and file sys¬ 
tems. It should be clear, then, that 
among the important features of 
an operating system used for 
development are the availability, 
generality, flexibility, and porta¬ 
bility of these models and tools. 

An ongoing project comes to 
mind that illustrates how some of 
the features offered under UNIX 
are helpful when applied to a 
specific class of scientific data 
analysis. In the August, 1985, 
issue of UNIX REVIEW, Paula Haw¬ 
thorn describes array processors 
as backend machines that are 
used to offload specialized tasks 
from the general-purpose hosts 
that they serve. An increasingly 
popular configuration for these 
allows you to embed a few small 
modules in your system by plug¬ 
ging them right onto the host's 
bus. While less capable than their 
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larger, standalone counterparts, 
they are often easier to use and 
less expensive to purchase and 
maintain. We recently purchased 
one of these and have begun to 
put together some of the building 
blocks to do time-series analysis 
with it. 

After installing the hardware, 
we began to unpack the software 
that came with the unit. Since 
several people were to work on the 
project, we had to try to find a 
sensible home for all of the var¬ 
ious pieces, but we discovered 
that some of the objects we had to 
deal with were a little foreign to 
our experience. The compiler and 
linker supplied for the develop¬ 
ment of AP microcode followed 
UNIX conventions closely enough 
that they could be installed in an 
official place for all to use. But 
what were we to do with all those 
things called task files that the 
compiler and linker produced? 
And what about the mini-operat¬ 
ing system for the AP that has to 
be downloaded with each task in 
order to run? 

During the previous several 
years of working with UNIX, we 
had adopted a uniform directory 
template for software develop¬ 
ment projects. Once we under¬ 
stood where task files fit and 
knew what other pieces of soft¬ 
ware would need to find them, we 
easily determined how to extend 
this system to accommodate 
them and even how to build 
makefiles to provide for their 
maintenance. Because the mech¬ 
anism embodied in the make 
utility is so general, we instant¬ 
ly had a powerful tool at our dis¬ 
posal for dealing with what 
turned out to be a relatively com¬ 
plex and recalcitrant hardware/ 
software subsystem. This turned 
out to have hidden benefits that 
showed up not long afterwards. 

Following a few weeks of deal¬ 
ing with the all too common 
problems of incomplete and mis¬ 


leading documentation and wres¬ 
tling with the hidden eccentric¬ 
ities that all new systems exhibit, 
we became fairly confident that 
we would be able to produce some 
spectacular processing by the 
time we received a visit from the 
people funding the project. Since 
plugging in the unit worked in 
much the same way as a floating 
point accelerator, it probably was 
not illogical for the clients to 
assume that the unit would be 
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installed in the system in such a 
way that other software could 
continue to function in its ab¬ 
sence, with only a speed penalty 
to pay. While attempting to ex¬ 
plain to these clients why the 
world really didn't work that 
way , it occurred to me that if we 
took a larger view of our objec¬ 
tives, maybe the world really 
should (and could) work that way. 

One of my golden rales is that 
unless a really significant im¬ 
provement in functionality or ca¬ 
pacity can be achieved by hack¬ 
ing the kernel , we don’t. If you 
consider device drivers as part of 
the kernel, however, I violate my 
rule routinely. For this reason, we 
rejected the idea of developing a 
full implementation using the 
trap mechanism or of modifying 
the C system libraries. We did so 
because we felt these approaches 


would be too intrusive for our 
tastes. Instead, we investigated 
the method of substituting a fun¬ 
ny device driver for one we used at 
the time to talk to the AP. Al¬ 
though we knew this probably 
would make the kernel grow sub¬ 
stantially larger, it looked like an 
attractive idea. 

What we finally settled on, 
though—for the time being at 
least—was a parallel library ap¬ 
proach. In order for a processing 
module using the AP to interface 
with the rest of the system, it 
must be wrapped in some C 
clothing (which could be woven 
together using Fortran, or any 
other language for that matter; 
the point is that one must have 
software that runs in the host). By 
devising a naming convention for 
accessing task files, we were able 
to implement modules that could 
be emulated exactly by host-only 
software that had been carefully 
placed in a parallel library, with 
entry points accessible by identi¬ 
cal calling sequences. Had I the 
source to the AP linker and the 
time to do it, I truly would have 
liked to make the linker under¬ 
stand the files produced by the ar 
utility, thus making the job of 
building task files measurably 
easier. 

The organization of some of the 
processing schemes we have ex¬ 
plored suggests that, for some 
applications, a host module may 
want to download several task 
files successively. For this reason, 
we might have explored archiving 
task files into libraries that could 
be accessed at runtime. Alterna¬ 
tively, since AP code can be 
expressed in a relatively compact 
fashion, we also could have de¬ 
vised a scheme under which it 
could be viewed by the host 
software in much the same way 
that compile-time initialized data 
is viewed (this is the sort of 
interface provided with many 
APs). If we had adopted symbol 
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applications) are almost certainly 
ill-advised, but an understanding 
of the specifics of the application 
at hand may well lead to a UNIX 
solution. 

What can be said of the solu¬ 
tions we eventually settled on? 
Were we able to achieve accept¬ 
able data acquisition throughput 
at an acceptable cost in hardware 
by using UNIX? Yes, given the 
other goals of our project. Were we 
able to sustain a high-volume 
processing environment under 
UNIX? Yes, given the flexibility 
required of our approach. Can 
specialized versions of UNIX that 
have been tailored for specific 
environments still be considered 
UNIX? This can be a religious 
question, since what you like 
about UNIX will largely determine 


what you think UNIX is or should 
be. Is UNIX really grown up 
enough to support large-scale sci¬ 
entific research, given the variety 
of processing constraints scienti¬ 
fic problems impose? I think it is, 
but only time will tell. 


Mr. Goff is Vice President for 
Computer Applications at Science 
Horizons Inc., a California research 
firm. Before helping to found this 
organization, he served as Staff 
Scientist and Senior Systems Engi¬ 
neer for Systems, Science and Soft¬ 
ware (now S-Cubed) for approxi¬ 
mately 11 years. During this time he 
was a key contributor to software 
systems now in use at the Center For 
Seismic Studies, a UNIX-based, 
DARPA-sponsored seismic research 
facility. ■ 
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J\ichardson. TX, seems like 
an unlikely locale for a guy from 
Brooklyn, but Steve Wallach 
seems to have adjusted to his 
new home. As the Vice Presi¬ 
dent of Technology for an ex¬ 
panding, young company, he 
has taken part in the area's 
growth—and as a fellow with 
big ideas, he has demonstrated 
a Texas-style appreciation for 
the proper scale of things. 

It was a little over a year ago 
that Convex unveiled the C-l, a 
64-bit integrated vector pro¬ 
cessing system said to offer a 
quarter of the power of a Cray 
for a tenth of the cost. The 
numbers the C-l has put up, in 
fact, are impressive: able to 
handle up to 128 MB of memory, 
the machine has been bench- 
marked at 60 megajlops. 

The notoriety this innovation 
has brought is familiar stuff 
to Wallach. Indeed, it was 
Wallach's own notoriety that 
helped launch Convex. As one 
of the featured characters in 
Tracy Kidder's best-selling The 
Soul of a New Machine (Little, 
Brown, 1981), Wallach has long 
had a reputation good for open¬ 
ing doors. 

In the book. Wallach was 
portrayed in his role as the 
principal architect behind Data 
General's 32-bit Eclipse super¬ 
mini series. Later, he served as 
Product Marketing Manager for 
Rolm Corporation's 32-bit MIL- 
spec minicomputer. 

To explore the suitability of 
UNIX for number crunching, 
UNIX REVIEW asked Rob War- 
nock, who is himself an in¬ 
dependent computer architect 
with nearly 20 years of experi¬ 
ence, to ask Wallach about 
some of the problems that al¬ 
ready have been dealt with — 
as well as some of those that 
have not. 


REVIEW: There seem to be a 
large number of companies pro¬ 
ducing what you call “ afforda¬ 
ble supercomputers". Why is 
that? 



THINKING 

BIG 


An interview with Steve Wallach 
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WALLACH: The reason is actual¬ 
ly fairly simple. There’s a phe¬ 
nomenal gap in the market. 
When we started this company 
[Convex], the companies making 
32-bit superminis were talking 
about how the next big market 
was going to be office ai tomation. 
It was clear that they weren’t 
going to do anything tc solve the 
problems of the people trying to 
do simulations. The folks in the 
scientific market just aren’t in¬ 
terested in office automation and 
menu-driven editors. r "hey want 
their Fortran and C programs to 
run fast. So we saw ar opening. 

New companies tend to be most 
successful when they re able to 
create a new markei. Tandem 
created a market. Apple created a 
market. And we’re creating a 
market. Much like those other 
companies, we’ve identified a 
niche and we’re right on it. 
Now—like in everything else— 
once you see a good tf ing, every¬ 
one immediately follows. 
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the level of your most constrained 
component. You only can go as 
fast as the slowest chip. 

Micro architectures simply are 
inappropriate for a lot of the 
applications out in the market. To 
be quite honest, a lot of the micros 
are just overgrown 8-bit and 16- 
bit machines, but people still try 
to run 64-bit problems on them. 

There’s also another issue. Ev¬ 
eryone talks about CPU perfor¬ 
mance these days, but the major¬ 
ity of applications out there are 
memory-bound and I/O-bound. 
It’s important to know how much 
main memory you have and how 
fast your I/O is. That may have 
more of an effect on your perfor¬ 


mance than anything else. 

REVIEW: Does Amdahl's Rule 
apply in the computer environ¬ 
ment? [Amdahl's Rule holds 
that for each instruction per 
second a machine should have 
one byte of main memory and 
one byte per second of I/O band¬ 
width.] 

WALLACH: It applies to every 
machine, but everybody seems to 
get hung up on the CPU. Let me 
give you a simple example: I have 
one machine that cranks out 20 
MIPS and another machine that 
does 10 MIPS. The 20 MIPS ma¬ 
chine has 20 MB of memory, in 
keeping with Amdahl’s Rule. The 
10 MIPS machine has 100 MB of 
memory. My application happens 
to have 100 MB of data, which is 
to be referenced several times 
during the execution of the pro¬ 
gram. In the latter case, that 
means that every time I make a 
reference to memory, my data is 
always there. On the 20 MIPS 
machine, 80 percent of my refer¬ 
ences are going to go to disk, 
which means 18 msec access time 
per access. Guess what? The 10 
MIPS machine runs the applica¬ 
tion faster. 

Applications and the people 
who buy computers are get- 
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ting more sophisticated. Rather 
than just running CPU bench¬ 
marks, now there are system- 
level benchmarks that look at I/O 
and determine how sensitive it is 
to physical memory. 

REVIEW: The second part of 
Amdahl's Rule holds that you 
should have one byte per sec¬ 
ond of I/O for every byte of 
memory . 

WALLACH: Look, at one point 
there was a thing called Gross’s 
Law. It claimed that you needed to 
spend the square root of price to 
double your performance. Now, 
of course, we know that’s bull¬ 
shit. Just compare the VAX and 
the MicroVAX II. Semiconduc¬ 
tor technology obviously has 
trashed that law. With higher- 
performance I/O and higher-per¬ 
formance main memory, I think 
the rules have changed. Like with 
the Cray 2 and its two gigabytes of 
physical memory: if you put ev¬ 
erything in memory, who cares 
about I/O? 

REVIEW: Are you already feel¬ 
ing a push to put more than 128 
MB on your system? 

WALLACH: Yes, a strong push, in 
fact. When we started the com¬ 
pany and said we were intending 
to build a system with 120 MB of 
memory, people said, “God, what 
a waste of time and effort! Who in 
hell is going to buy that? Just 
think of the expense!’’ That’s 
because no one anticipated that 
the price of 256K RAMs would fall 
as much as it has. We now hear 
that, “Customers lust for mem¬ 
ory. ’ ’ 

I always explain this by telling 
a joke: A guy walks up to an 
Indian who is saying, “Chance, 
chance.’’ So the fellow asks, 
“‘Chance’? I thought Indians al¬ 
ways said ‘how’?’’ “No”, says the 
Indian. “Already know how, just 
want chance.’’ Supercomputer 
users always knew what they 


could do with more physical 
memory if they had it, but they 
never got the chance because— 
unless you worked for the govern¬ 
ment—you couldn’t get your 
hands on a machine with a giga¬ 
byte of memory. Now, though, we 
actually have sold several ma¬ 
chines with over 100 MB of 
memory. 

Thus, the question becomes: 
do you really have to have all that 
memory? Yes, even for UNIX. 
This is interesting: 4.2BSD has a 
notion of disk cache that keeps 
you from having to go to disk if 
your block data can be located by 
the software that maintains the 
cache. With all this physical 
memory, we can make the disk 
cache as big as we like, so when¬ 
ever we run up against I/O bench¬ 
marks, we just define a disk 
cache large enough to keep us 
from having to go out to disk. As 
a result, our machines have 
screamed through benchmarks. 
Some people cry, “Foul! That’s 
not a fair benchmark because I 
can’t do that on my VAX’’—to 
which, of course, we respond, 
“Right”. Then we smile and don’t 
say anything more. 

REVIEW: Besides disk cache , 
what aspects of UNIX have you 
found well suited to your 
needs? 

WALLACH: Most things are fine. 
But the I/O structure is really 
lacking for a Convex-class 
machine. 

REVIEW: What aspect of I/O is 
a problem? The fact that it's 
synchronous? 

WALLACH: Yes. And to deal with 
that, we’ve added disk striping— 
just like you now have on a Cray. 
Striping allows you to take one 
disk file and make it go across 
multiple spindles. For example, 
we can get approximately 1 MB a 
second out of a single Fujitsu 
Eagle. A file striped across four 


Fujitsu Eagles, though, can get 4 
MB a second of I/O. We’ve also 
added asynchronous I/O, mean¬ 
ing that if you do a disk or tape 
reference, you can keep going and 
use the signal mechanism of 4.2 
to synchronize yourself. That’s 
an issue that always comes up. 

REVIEW: Why did you choose 
4.2 over System V? 

WALLACH: When we started the 
company in September of 1982, 
we knew we wanted to put togeth¬ 
er a virtual memory machine. 
Berkeley had a virtual memory 
system; System V did not. We 
wanted networking and TCP/IP: 
4.2 had it; System V did not. And, 
let’s face it, 4.2 traditionally has 
focused more on scientific appli¬ 
cations than on commercial ones. 
Since we’re after a scientific cus¬ 
tomer base, 4.2 made sense. We 
just made a business decision. 

REVIEW: So is 4.2 that much 
better suited to scientific appli¬ 
cations? 

WALLACH: At a base level. But 
neither 4.2 nor System V has the 
capabilities that a lot of people 
want. They don’t have the disk 
striping or asynchronous I/O— 
and they lack a lot of real-time 
features like pre-emptive sched¬ 
uling and the ability to lock pages 
into physical memory. What it 
boils down to is that the majority 
of scientific users are accustomed 
to their VMS, CDC, or Cray oper¬ 
ating systems. Now, when they 
look at UNIX, they say, “This is 
great. But I’m used to these five 
features. Put them on and you’ve 
got a sale.” They don’t care about 
UNIX, SCHMUN1X. It’s features, 
functions, and benefits that they 
want. 

REVIEW: I've always thought 
that I'd be happy if I could get 
my hands on a UNIX system 
that had TOPS-10 real-time 
features. 
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FORTRIX 


can cost you a bundle! 


The bundle we're referring to consists of your 
existing FORTRAN programs and files. Costly items 
you'll have to discard when you move up to C, 
unless you save them with 
FORTRIX™! 

Here at last is a program that 
automatically and rapidly converts 
FORTRAN code to C code, allowing 
you to salvage your FORTRAN 
material at approximately 600 lines 
per minute. This incredible speed 
allows a single programmer to con¬ 
vert, debug and put into operation a 
typical 50,000 line package in only 
one to two weeks. Plus, the resulting 
"C" program will run 15% to 30% 
faster than the original FORTRAN 
program, while occupying 35% less 
disk space! And the system even 
helps you learn coding in C language | 

as you compare your own familiar 
FORTRAN programs with the 
corresponding C language w J 

programs generated by m 't J 

FORTRIX.™ ' ' 


There's a complete selection of FORTRIX™ versions 
to suit the full range of user requirements: Original 
FORTRIX™-C, which translates FORTRAN code to C 

code, allowing input data files to remain 
fully compatible with your new C pro¬ 
gram; FORTRIX™-C +, with the added 
ability to handle COMMON and 
EQUIVALENCE statements, character 
handling and direct I/O; FORTRIX™-C', the 
complete FORTRIX™-C+ package con¬ 
figured for non-UNIX* systems including 
VAX/VMS; and FORTRIX™-C/micro. stand¬ 
ard FORTRIX configured for use on the 
IBM PC and compatibles. 

FORTRIX™ has already been installed 
on 26 different brands of hardware, so 
whichever FORTRIX™ version meets your needs, you 
can be sure it will exceed your expectations in terms 
of speed and cost savings realized. Why not act now 

to save your bundle? Get full technical details, 
plus references from among over 100 
satisfied licensees, from Jim Flynn at (212) 
687-6255, Extension 44, or write to him at 
Rapitech Systems Inc., Dept. A2, 
wfV 565 Fifth Avenue, New York, NY 10017. 




FORTRIXr Fortran-to-C Conversionware™ from 

Rapitech 
Systems Inc. 




Telephone (212) 687-6255/Telex 509210 


‘UNIX is a trademark of AT&T Bell Laboratories 
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WALLACH INTERVIEW 


WALLACH: Then you might be 
interested in knowing that we 
have a customer who’s bringing 
up a TOPS-20 shell on top of 
UNIX. There are a lot of program¬ 
mers who are used to TOPS-20. 

REVIEW: In light of that, why 
has UNIX taken over the super¬ 
computer so quickly? 

WALLACH: It’s very simple— 
standards. In any DP shop, the 
biggest life-cycle cost is Joe in the 
software department. When peo¬ 
ple come out of school today, they 
tend to know UNIX. If you’re 
trying to hire programmers, you 
pay attention to that because you 
know if you have UNIX, your new 
hires are productive after a week. 
If you have some proprietary 
operating system, you’re looking 
at a six-month training cycle. 
That and the transportability of 
code are the name of the game for 
UNIX. 

REVIEW: At one time, many 
vendors were afraid of stan¬ 
dard operating systems.fearing 
that their customers might 
leave. Has that changed? 

WALLACH: The bigger you are, 
the less you like standards be¬ 
cause you want to lock people in. 
Standards mean that the lock 
these companies once had isn’t a 
lock any more. 

REVIEW: Has your commitment 
to UNIX caused you any busi¬ 
ness problems? 

WALLACH: The only problems 
relate back to the fact that while 
these people want to use UNIX, 
they also want maybe 10 func¬ 
tions from their old operating 
system—like one for tape han¬ 
dling, for example. You know, 
UNIX is not very big on handling 
magnetic tapes. But certain in¬ 
dustries are very dependent on 
tape—the geophysical [oil] indus¬ 
try, for example. UNIX also does 
not support IBM communica¬ 


tions, but, believe it or not, there 
are still lots of people out there 
who want IBM communications. 
So the problem is that while UNIX 
is a very good development sys¬ 
tem, it has some real drawbacks 
in a production environment. 
Most of the time we’ve spent on 
UNIX has been used to build up 
production and real-time capa¬ 
bilities—as well as some system 
management features so that 


Everyone talks about 
CPU performance 
these days, but the 
majority of 

applications out there 
are memory-bound 
and l/O-bound. 


customers don’t have to hire a 
Ph.D. from UC Berkeley to handle 
their system administration. 

One of the things that we’ve 
found as we’ve added these fea¬ 
tures, though, is that people will 
say, ’’That’s not within the UNIX 
philosophy. That’s not UNIX- 
like.” But our idea is that if 
there’s someone out there who 
has hard cash and wants to buy 
some machines that have certain 
features, we’re going to say, “Yes, 
sir.” 

REVIEW: What about compati¬ 
bility? 

WALLACH: These extra features 
always are extensions, not mod¬ 
ifications. 

REVIEW: Besides the need for 
extra features, have you come 
across aspects of UNIX or C that 
have caused you problems? I 
would imagine, for instance, 
that you're more used to work¬ 
ing with Fortran arrays than 
with C’s pointer types. 
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WALLACH: Yes, thst’s very im¬ 
portant, in fact. / lot of our 
optimizations and a lot of our 
features come frorr application 
software. Rather tnan figuring 
out what to do next, we let 
benchmarks and user code drive 
the functionality. We’re a very 
market-driven company. I can 
point to features in the architec¬ 
ture, the compiler, and the oper¬ 
ating system, and hen point to 
pieces of major third-party soft¬ 
ware that stress these features. 
Asynchronous I/O is in all the 
finite element codes, like NAS- 
TRAN and ANSY5. Striping is 
useful in fluid dynamics code, as 
seismic interpretatiDn is in reser¬ 
voir models. 

It’s my opinion that the com¬ 
panies that succeed will be the 
ones that recognize what their 
customers need. No oody wants or 
can afford to hire any more pro¬ 
grammers. Compar ies want ven¬ 
dors to produce tools that will 
allow them to increase the pro¬ 
ductivity of the programmers they 
already have. 

I have an interesting story 
about that. Among many other 
optimizations, our compiler does 
what is called “dead code elim¬ 
ination’’. That is, if a piece of 
code is never execu :ed, we can de¬ 
tect it. Every so often, someone 
will bring in a benchmark that 
was written 10 years ago, and- 
like everything el 
patched for 10 years. We’ll run it 
through our compiler and get 
back the message 
so, dead code n: 
fellow will look at 
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“What does that mean?” When 
we tell him that the code was 
never executed, he’ll go back and 
start tracing and sooner or later 
he’ll say, “I’ll be darned, you’re 
right. I’ve been maintaining a 
piece of code for 10 years that’s 
never been executed.’’ 

When we first started, the only 
thing we pitched was MIPS and 
megaflops. Don’t get me wrong— 
we still do that. But, more and 
more, the buy decisions are being 
made on the basis of productivity 
issues. 

Not to downplay the impor¬ 
tance of hardware, but we now 
have more software people than 


hardware people. That’s basically 
where you have to focus. Hard¬ 
ware people, of course, can be 
much more productive now be¬ 
cause of CAD. In fact, compared 
to the [Data General] MV-8000, 
we had less people working on the 
design of this machine [at Con¬ 
vex]—even though it’s probably 
an order of magnitude more com¬ 
plex than the MV-8000. That’s a 
very good milestone in my book. I 
should point out that in all my 
years of computer development, I 
have never worked with a more 
talented or gifted team of people 
than here at Convex. In 15 
months, the designers had a pro¬ 
totype working with full VLSI— 
running UNIX and executing code 
generated by our Fortran com¬ 
piler. 

REVIEW: Are there any aspects 
of UNIX that seem to cause 
problems for large-machine ar¬ 
chitectures? Right off hand, I 
would think that heavy use of 
character-at-a-time I/O would 
cause a lot of context switching. 
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WALLACH: We put a sledgeham¬ 
mer to that. All the character I/O 
is off-board on IOPs [I/O proces¬ 
sors]. One of the best experiences 
we had with that occurred on 
a prototype. We were printing 
out something when the CPU 
stopped—but we didn’t know it. 
We were still printing voluminous 
lines and pages. That’s because 
there are no device drivers in the 
CPU—they’re all on IOPs. So 
what happens is that when you 
print on a line printer, the kernel 
executing on the CPU supplies a 
byte number and byte count. It 
then interrupts the IOP, and 
leaves it to do its own work. 
That’s what an MC68000 is really 
good for, as opposed to a high¬ 
speed processor. We can use 
68000s to totally offload all disk 
I/O, all tape I/O, and all character 
I/O. 

REVIEW: Does this make it pos¬ 
sible for customers , for exam¬ 
ple ■, to write their own device 
drivers without having to learn 
your machine language? 

WALLACH: Yeah—and what is 
more, all the device drivers are 
written in C. Even the diagnostics 
are written in C. You can go from 
disk to tape over the I/O bus 
without using the CPU. The thing 
is: when we built this machine, 
we built a system. My experience 
has taught me that, while every¬ 
one focuses on CPUs, they let the 
I/O go by the wayside. But you’ve 
go to hit it with a sledgeham¬ 
mer—which by the way is some¬ 
thing DEC hasn’t done yet. The 
VAX is a very slow “eye opener’’. 
It was built as a minicomputer, 
you know. 

REVIEW: Speaking of minicom¬ 
puters, has your Data Gener¬ 
al experience—your notoriety 
with the MV-8000—been an 
asset or a liability? 

WALLACH: Actually, it’s been a 
massive asset. Since my life is a 


living resume, there’s very little I 
could hide even if I wanted to. 
Companies that we deal with can 
figure out that we didn’t just 
decide to build this machine yes¬ 
terday even though they don’t 
actually know what we were do¬ 
ing. There’s a big advantage in 
having a very public resume. You 
know, the old joke is that when 
Bobby Thompson hit his home 
run in Ebbetts Field, there were 
30,000 people there, but 10 years 
later, if you had walked around 
Brooklyn, you’d have sworn that 
300,000 people had been at the 
game. We’ve all seen resumes of 
people we’ve worked with five 
years earlier and seen things we 
know aren’t true. It’s great to 
have some credibility. 

REVIEW: The process is called 
“due diligence ”, I believe, 

WALLACH: That’s right. When 
we were raising money, the ven¬ 
ture capitalists made a run on 
bookstores to get copies of The 
Soul of a New Machine , because 
I would tell them, “Look, just read 
the book. It’s fairly accurate.” 

REVIEW: You seem to enjoy at¬ 
tacks on the big powers. Does 
that belong in your resume? 

WALLACH: Absolutely. In fact, 
the biggest thrill for me is the 
challenge. I’ve never backed 
away from one yet. I’m one of 
those people who shouldn’t be 
kept around if I’m not motivated. 
You’d be better off getting a clerk 
to do the job. I think a lot of people 
around me feel the same way. 
We’re doing battle now with the 
big powers, which for reasons 
known only to themselves have 
lost their focus on the scientific 
market. If you’re working on 
something you believe in, are 
having a bit of fun, and are 
making some money to boot, who 
can ask for more? 

REVIEW: Do you find that cer¬ 
tain general design decisions 


tend to live a long time and that 
you end up applying them over 
and over? 

WALLACH: In a way, yes. I once 
met Gene Amdahl at a confer¬ 
ence. This was back when he had 
just announced his 470 at Am¬ 
dahl Corporation. I asked him if 
the machine offered IBM 1401 
emulation because a lot of the 
360s had it. And he responded, 
“The son should not pay for the 
sins of the grandfathers.” You 
know, at some point we’ve got to 
stop propagating mistakes. 

REVIEW: You said earlier that 
you had found yourself using 
some of the features of an APL 
machine you designed in 1971 
in the Convex computer. 

WALLACH: That’s right. We 
used some features—some con¬ 
cepts—because they worked be¬ 
fore. You know, if a wheel is 
round, it can be used by a car. 
Let’s have a round wheel. 

REVIEW: Is UNIX a wheel? 

WALLACH: That’s a good ques¬ 
tion. I think it’s more a level and 
fulcrum than a wheel. The best 
thing that can happen to UNIX— 
strictly from a business view¬ 
point—is for the schism between 
System V and 4.2BSD to disap¬ 
pear. As a manufacturer, I’d love 
to see it. It would be beautiful if 
UNIX were brought under some 
sort of ANSI control. Then, at 
least, there would be a defined 
document not under the control 
of a single manufacturer. [The 
IEEE PI003 Committee is, in 
fact, at work on a UNIX standard 
definition as of this writing.] 

REVIEW: Is there any prece¬ 
dent for such independent con¬ 
trol of operating system stan¬ 
dards? 

WALLACH: To my knowledge, 
no. But that doesn’t mean it can’t 
be done. Lack of precedents cer¬ 
tainly never stopped UNIX. ■ 
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When you learn the L NIX™ System directly from 
AT&T, you learn it fror l the people who develop it. So 
all the information you get is firsthand. 

For over fifteen yea rs, we’ve been teaching our peo¬ 
ple to use the UNIX System—which makes us the best 
trained to help you le; irn. 

The best training starts at your own terminal. That’s 
why, at AT&T each sti dent gets the use of an individual 
terminal for real ham Is-on training. 

Take your pick of c ourses from our extensive cur¬ 
riculum. Whatever your level of expertise, from first¬ 
time user to system (eveloper, we 
have a course that will suit your 
individual needs. And all our 
courses are designee. to teach you 
the specific skills that will soon 
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Continued from Page 26 
the discussion below.) 

• Several implementations of sub¬ 
routine libraries compliant 
with Graphics Kernel System 
are available for use on UNIX 
systems. 

• Many standard UNIX utilities 
provide for interactive data 
analysis and display (awk, plot, 
hist, and S, among others). 

In addition to these facilities, 
several other UNIX system utili¬ 
ties can provide significant sup¬ 
port during the software develop¬ 
ment cycle. These include vi, 
make, SCCS/RCS, and the sys¬ 
tem’s various document prepara¬ 
tion tools. 

Note that UNIX, as it is com¬ 
monly delivered, is not able to 
provide the facilities necessary 
to support event-driven applica¬ 
tions. This does not imply that 
the system can never be used in 
such a capacity, but it does indi¬ 
cate that kernel modifications 
typically are required to integrate 
a UNIX-based computer into real¬ 
time applications. 

THE FORTRAN PROBLEM 

By now, it should be apparent 
that the single most important 
demand made by scientific appli¬ 
cations of an operating system is 
for an optimizing Fortran compil¬ 
er with a robust, standard For¬ 
tran runtime library. The f77 
compiler does not satisfy this 
requirement very well. It is impor¬ 
tant to look into the reasons for 
the deficiency, and to see how the 
problem can be rectified. 

UNIX achieved its first notori¬ 
ety as a system programming and 
document preparation engine, 
neither of which require much in 
the way of floating point sup¬ 
port. C, meanwhile, is an excel¬ 
lent systems implementation lan¬ 
guage. and is the source language 
of most of the UNIX system. As a 


result, most work in compiler 
optimization for UNIX systems is 
devoted to C. 

Development of compilers for 
different high-level languages on 
the same system can follow two 
general approaches: 1) each com¬ 
piles the source code directly into 
object code, or 2) each compiles 


UNIX provides many of 
the facilities necessary 
to support the 
computationally 
intensive class of 
scientific applications. 


the source code to an intermedi¬ 
ate representation that a single¬ 
code generator then can use to 
produce object code. In the first 
case, the compiler writer can 
generate object code that takes 
maximum advantage of the in¬ 
struction set of the machine: in 
the latter, the compiler writer can 
generate intermediate code that 
maximizes use of the intermedi¬ 
ate machine architecture. Despite 
the portability and economies of 
scale represented by the second 
scenario, efficient object code 
generation is dependent on the 
richness of the intermediate ma¬ 
chine architecture. 

The f77 compiler under UNIX 
uses the intermediate approach 
for object code generation, taking 
advantage of the code generator 
offered by the system’s C compil¬ 
er. Unfortunately, many of the 
classic programming idioms em¬ 
ployed by Fortran programmers 
are not typical of the way C 
programs use machine resources. 


As a result, there is a poor match 
between the idioms and C’s inter¬ 
mediate machine architecture, 
leading to non-optimal object 
code for many of the most heavily 
used Fortran constructs. 

One possible solution to this 
quandary is to convince scientists 
to use a different language. Much 
has been learned concerning the 
use of program and data struc¬ 
tures since the first Fortran com¬ 
pilers appeared. The lack of gen¬ 
eral data structures and a pointer 
data type often cause algorithms 
that are really quite simple (when 
expressed in a modern structured 
language) to take on the appear¬ 
ance of spaghetti when expressed 
in Fortran. A new language will 
not succeed, though, unless it can 
be shown unequivocally to out¬ 
perform Fortran in candidate sci¬ 
entific applications. Only then 
will scientists be induced to ac¬ 
cept the startup costs of learning 
a new language. 

Another possible way to in¬ 
crease the appeal of UNIX for the 
scientific community is to aban¬ 
don f77 and develop an optimiz¬ 
ing Fortran compiler that com¬ 
piles source code directly into 
object code. The portability of the 
UNIX system permits vendors to 
quickly provide a proven, sophis¬ 
ticated, multi-programming oper¬ 
ating system. With an optimizing 
Fortran compiler, these same 
vendors would be able to increase 
their penetration of the scientific 
and engineering market sectors. 

THE FUTURE IS NOW 

The major roadblock to a more 
general acceptance of UNIX in 
the scientific community is the 
availability of an optimizing For¬ 
tran compiler for each particular 
hardware architecture. Despite 
the revulsion purists experience 
when contemplating such a proj¬ 
ect, several manufacturers are 
starting to pursue this approach. 
This is especially true among the 
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supercomputer vendors. Note 
that though the Cray 2 provides a 
UNIX environment, it makes use 
of its own optimizing Fortran 
compiler. The same applies to 
Convex Computer Coi p. and oth¬ 
er “affordable supercomputer” 
manufacturers. 

Most UNIX systens provide 
little of the necessary support for 
event-driven applica ions. Some 
companies have attempted to 
provide such facilities, but only 
at the expense of making ma¬ 
jor changes in the underlying 
UNIX kernel. It is also true (at 
least in the experimental physics 
community) that rruch of the 
data acquisition anc experimen¬ 


tal control perform 
systems is handled 


ed by such 
by dedicated 


microprocessor systems running 
standalone operating system ker¬ 
nels. The communication be¬ 
tween these micros and other 
timesharing hosts typically oc¬ 
curs by way of standard local area 
networks. Thus, the need for 
a standard operating system 
to support event-driven applica¬ 
tions is substantially reduced. 

Of course, one can always hope 
that a structured successor to 
Fortran will eventually emerge. 
Despite the improved program¬ 
ming environment such a lan¬ 
guage would undoubtedly pro¬ 
vide, its performance will have to 
be vastly superior to today’s For¬ 
tran if it is to win general accep¬ 
tance in the scientific communi¬ 
ty. In the meantime, we will 


find that Fortran continues to 
be heavily used in scientific ap¬ 
plications, and that scientists 
continue to pass up UNIX sys¬ 
tems unless they can be shown 
that UNIX satisfies their Fortran 
needs in a realistic manner. 

Joe Sventek is a member of the 
Computer Science research staff at 
Lawrence Berkeley Laboratory and 
a member of the Computer Science 
faculty at the University of Califor¬ 
nia at Berkeley. In a previous life, he 
authored programs representative 
of both general categories of scienti¬ 
fic applications—none of which 
were crafted or run on UNIX 
systems. ■ 

Copyright 1985 by Joseph S. Sventek. 
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DATA ANALYSIS 
THROUGH INTERACTION 


Use of the S system to emphasize human effectiveness 

by Richard A. Becker and John M. Chambers 


is a language 
and a system for the interactive analysis of data. 
The system has applications in any field where data 
is involved: financial analysis, business graphics, 
quality control, engineering, and many more. It runs 
under the UNIX operating system and is described 
in detail by a 550-page user’s guide, S: An 
Interactive Environment for Data Analysis and 
Graphics , by Becker and Chambers (Wadsworth, 
1984). The system is currently used by businesses, 
universities, and research laboratories. Although it 
is hard to be precise, we know that there are 
hundreds of S sites and thousands of users. 

The design goal for S, stated most broadly, is to 
enable and encourage good data analysis. S 
provides users with an environment that helps 
them look quickly and conveniently at many 
displays, summaries, and models for their data. It 
allows the user to follow the kind of iterative, 
exploratory path that most often leads to a thorough 
analysis. By typing simple but general expressions 
to the system, the user gets immediate, informative 
feedback, possibly including output on a graphical 
device. In addition, the system is open to change; 
even though the S system has many capabilities, a 
variety of mechanisms are available for extending 
the system as new applications and techniques 
appear. 

OVERALL ORGANIZATION 

An S user types expressions that describe the 
analysis to be done. Some examples can be found in 
Figure 1. The expressions involve a wide variety of 
operators and Junctions that carry out arithmetic 
and mathematical operations, statistical analyses, 
graphics, data manipulation, and other computa¬ 
tions. Expressions also use and create datasets 
containing data structures, such as vectors, arrays, 
time series, and tables. Datasets are automatically 
accessed by name. The S executive interactively 
parses expressions and controls their evaluation. 

The organization of S resembles that of an 
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THE S SYSTEM 


# read a vector of numbers from a file, create data set mydata 
mydata read("my.data.file") 

mydata - mean(mydata) * subtract the mean from each value 

« Given a matrix of predictor variables longley.x 
« and a response variable longley.y 

* get the residuals from a multiple linear regression model 
r regress(longley.x.longley.y)$resid 

# compute the residuals 

* larger than the median absolute residual 
r [ abs(r) > median(abs(r)) ] 


Figure 1 — Some sample S expressions. 

interactive operating system: the executive corre¬ 
sponds to a command interpreter, the datasets 
relate to files, and the functions can be equated with 
individual commands. Specific similarity to the 
UNIX system organization is probably not coinci¬ 
dental, although it was not conscious. There are 
significant differences, however. The expressions 
for data analysis need a richer syntax than the 
commands in an operating system, particularly for 
algebraic expressions, and data for arguments and 
results need more structure (commands in the UNIX 
system operate largely on unstructured streams of 
bytes). 

S was designed in a research environment for 
statisticians who continually develop new tech¬ 
niques, so it was essential that the system be 
extensible. Some of this extension (macros and new 
data structures) can be done within the interpretive 
S language itself. Other extensions involve the 
creation of new S functions. Facilities for extension 
are intended for users; they are not restricted to 
those familiar with the internal workings of S. 

EXPRESSIONS: THE LANGUAGE 

The user who types expressions to an applica¬ 
tions system wants a combination of simplicity and 
flexibility. Simple requests should be straightfor¬ 
ward and brief. At the same time, unusual but 
sensible requests should not be impossible or 
unreasonably complicated. Novice and expert users 
will place different emphasis on the simple or the 
unusual. 

In S, all user commands follow one general 
syntax: everything is an expression. The expres¬ 
sions that are given to S may be as short or as long 
as is comfortable for the user. 

Expressions in S use functional and algebraic 
syntax, as Figure 1 shows. For users with some 
background in mathematics, science, or engineer¬ 


ing, this syntax is readable and familiar. Extensions 
to ordinary algebraic notation introduce a few 
special operators; for example, a colon is a sequence 
operator such that x:y is a vector going in steps of 
± 1 from x to y. 

When an expression is given to S, it is evaluated. 
The result may be assigned a name and thus saved 
as a dataset. If the result of an expression is not as¬ 
signed or used inside another expression, it is 
printed for the user. 

Algebraic notation (prefix or infix operators, in 
other words) is natural for functions with one or two 
arguments. However, data analysis quickly becomes 
involved with functions that have many arguments. 
Functions in S can have arbitrarily many argu¬ 
ments that can be specified by either position or 
name. Typical functions to carry out statistical or 
graphical analysis will have a few arguments to say 
what data is to be analyzed or plotted as well as 
many optional arguments to control details. Options 
are most easily supplied in the form name = value; 
the options of interest can be specified in any order. 
Functions return data structures that may have an 
arbitrary number of named components; thus, 
functions may have any number of inputs and 
produce any number of outputs. 

One of the most powerful functions in the S 
language is represented by the subscripting opera¬ 
tor. Since S deals with vectors, it is natural that sub¬ 
scripts are also vectors. Thus: 

X[ 1:5 ] 

returns the first five values in x. Since it is 
frequently necessary to exclude observations during 
data analysis, negative subscripts specify the values 
to be excluded: 

x[ -6 ] 

returns x with the sixth value omitted. 

Subscripting can also be used to answer data¬ 
base-like queries. Logical expressions used as 
subscripts cause the selection of data corresponding 
to TRUE values in the subscript. For example, the 
query “give the names of people under 25 who make 
more than $30,000“ would be expressed as: 

name[ age < 25 & salary > 30000 ] 

The subscripting operation extends naturally to 
multiway arrays, and in this context an empty 
subscript denotes all values in that subscript 
position. For a matrix y: 

y[ • 6:2 ] 
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THE S SYSTEM 


Specific similarity to the UNIX 
system organization is probably not 
coincidental, although it was not 
conscious. 


returns all rows of columns six through two. As this 
example illustrates, the subscript operator can also 
permute data values (here reordering columns six 
through two). 

The function order generates subscripts corre¬ 
sponding to a sorted version of its argument. Thus: 

x[ order(x) ] 

is equivalent to: 

sort(x) 

Using order also makes it simple to do passive 
sorting: 

name[ order(salary) ] 

lists names in increasing order of salaries. 

The print function, implicitly invoked whenever 
a result is not assigned, represents numerical 
results to the appropriate number of decimal places 
and can neatly lay out matrices, time series, 
multiway tables, and character data. 

The function apply is able to invoke another 
function repeatedly on portions of data structures. 
In its simplest form, apply invokes a function on 
each of the rows or columns of a matrix. Thus: 

apply( y. 1. "mean" ) 

invokes mean once on each row (dimension 1) of the 
matrix y and returns the vector of row means. With 
other choices for its second argument, apply can 
deal with slices of multiway arrays. Functions can 
also be applied over hierarchical data structures 
and ragged arrays. 

DATA STRUCTURES AND DATA MANAGEMENT 

Datasets in S contain self-describing, hierarchi¬ 
cal (list-like) data structures. Datasets are created 
automatically by assignment expressions; no user 


control of storage is required. The elementary data 
structures are vectors of numbers, logical values, or 
character strings: 

> response 

1.01 .97 3.1 7.21 

> response >2.5 

F F T T 

> species.name 

"Setosa" "Virginica" "Versicolor" 

(Here the “>” is the S prompt for an expression). 

The numeric data modes are “real” and “inte¬ 
ger”, but for the most part the distinction is 
unimportant to the user. In S, the value of the 
expression “3/2” is 1.5, even though in many 
programming languages integer arithmetic would 
produce an integer result of 1. A special operator is 
provided for integer division when it is needed. 

There is a special value, NA (not available), that 
can be used to signify missing data. Any arithmetic 
operations on NAs produce NAs. 

General data structures consist of any number of 
components, each component being either a vector 
or another general data structure. Each component 
has a component name ; syntactically, the compo¬ 
nent named Label of a structure z is denoted 
zSLabel. 

We designed S so that most users are unaware of 
the details of data structures, but also so that 
structures can be defined and manipulated easily to 
handle new analyses. Simplicity for the user is 
obtained because all functions that deal with a 
given type of data structure (for example, matrices, 
time series, or tree structures from clustering) 
recognize the structure type by looking for compo¬ 
nents with certain specific names. Functions that 
produce such structures as their value simply 
return structures with the appropriately named 
components. For example, a multiway array is 
defined as a structure with two vector components: 
one named Data containing the data values for the 
array (listed column-by-column), and one named 
Dim containing the extents of the array on each 
dimension. A 2 by 3 matrix, x, with data value 2i+j 
in the [i.j] position corresponds to the following list 
representation: 

( "x" STR 
( "Dim" INT 2 3 ) 

( "Data" REAL 3 5 4 6 5 7 ) 

) 

Certain functions make use of a list representation 
of S data structures to enable structures, or entire 
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THE S SYSTEM 


The user who types expressions to 
an applications system wants a 
combination of simplicity and 
flexibility. 


databases, to be written to files in character form 
and subsequently read back in. 

The ordinary user does not see this structure, 
however; x just appears to be a matrix. When a 
matrix or array is printed, it is laid out conventional¬ 
ly with no explicit reference to the components of 
the structure: 

> x 

Array: 

2 by 3 

Ml [.2] [.3] 

[1.] 3 4 5 

[ 2 .] 567 

Matrices and arrays are created and manipulated 
by a large number of S functions. Data structures 
such as arrays or time series are so widely 
recognized that they are considered to be built into 
the language. Most of the basic functions, such as 
arithmetic, logic, printing, and plotting, include 
some special facilities for treating these structures 
sensibly. For example, the result of adding together 
two time series is a time series on the intersection of 
the two time domains. 

A broader special class consists of vector struc¬ 
tures which are data structures that can act like 
vectors but have special structure in addition. 
Vector structures can be used in arithmetic and, in 
general, can act as a vector argument to any S 
function. Arrays and time series are examples of 
vector structures, but the class is open-ended. 
Internally, any structure with a vector component 
named Data is considered a vector structure. The 
Data component is the part that acts like a vector 
when necessary. Functions that operate element- 
by-element on a vector structure change the data 
values but leave the other components unaltered. If 
x is the matrix above, sin(x) produces a 2 by 3 ma¬ 
trix with data sin(3), and so forth, while x<4 is a 
matrix of logical values. 
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Functions that rearrange the order of elements, 
on the other hand, throw away the structure and 
leave just the data: sort(x) sorts the data values in 
the matrix but its result is a simple vector. Since the 
original design of S, vector structures have been 
added to represent such structures as distance 
measures, categorical variables, and multiway 
tables. These structures can be used as vectors 
throughout the language, with no modification of 
the various S functions involved. 

THE EXECUTIVE 

The S executive performs tasks roughly compara¬ 
ble to an operating system command interpreter 
(such as the UNIX system shell). It controls most 
interactions with the user, parses user expressions, 
schedules the execution of various functions, and 
handles interrupts and error recovery. 

User expressions are accepted by a parser built 
using the yacc compiler-compiler with a customized 
lexical analyzer. 

The process by which the executive invokes an S 
function is crucially system dependent. S consists of 
a large collection of functions (currently around 
300). Furthermore, users must be free to write and 
use their own functions. The facilities of the 
operating system running S determine how such a 
collection can be maintained and used in a 
reasonably efficient way. Operating system con¬ 
straints have forced us to use several different 
implementation strategies. For the original version 
of S, on a Honeywell computer with a relatively 
primitive operating system (no virtual memory or 
process control), we wrote our own dynamic loader. 
Each S function was an overlay, read in by the 
executive; control was passed by a standardized 
transfer vector. 

When we first moved S to PDP-1 Is running the 
UNIX system, the major constraint was the 16-bit 
program address space. For this environment, we 
implemented each S function as an independent 
program. The executive used the fork and exec 
operations to start up new processes, and they 
shared data by means of a common file and noted 
completion by means of signals. 

The current implementation on 32-bit hardware 
exploits the larger address space to incorporate 
some or all of the S functions as part of the program 
containing the executive. 

For our goals of flexibility and extensibility, it is 
essential that these changes in implementation 
affect only the executive, not the source code for 
individual functions. Even in the executive, only a 
relatively small fraction of the code is system- 
dependent. This code, however, is more crucial to 
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THE S SYSTEM 


Users often react to plots by finding 
the unexpected and using this new 
information to shape subsequent 
analysis. 


the reliability and efficiency of the system than its 
size might suggest—adapting the control of such a 
large-application software system to the features of 
a non-UNIX system is relatively difficult. 

GRAPHICS 

Data analysts use plots iteratively as an intimate 
part of their study of data. The unique role of plots 
comes from their information content: no other 
form of output conveys so much information so 
quickly. Users often react to plots by finding the 
unexpected and using this new information to 
shape subsequent analysis. A variety of graphical 
techniques for data analysis are presented in 
Graphical Methods jor Data Analysis , by Cham¬ 
bers, Cleveland, Kleiner, and Tukey (Wadsworth, 
1983). 

S emphasizes interactive graphics as one of the 
most important tools in data analysis. Graphics 
functions in S provide the simple displays that are 
predominant in statistical graphics—most notably 


the scatter plot—in a flexible and easy-to-use form. 
For example: 

plot(x.y) ^scatter plot 

qqnorm(x) ^Normal probability plots 

The general data structures and expressions in S 
help to provide graphical output from a variety of 
sources. Many analyses produce results that define 
a scatter plot: for example, a probability plot shows 
an ordered set of data plotted against corresponding 
quantiles of a probability distribution. Deviations 
from a straight-line pattern help assess distribu¬ 
tional assumptions. Rather than duplicating scat¬ 
ter-plot software for each such plot, S functions 
return as their value a plotting data structure , 
which is passed automatically to the plot function 
to be displayed. The expression: 

qqnorm(mydata) 

produces a probability plot of mydata against 
quantiles from the standard normal distribution. 
Internally, qqnorm only generates the plotting data 
structure and then invokes the scatter-plot func¬ 
tion; qqnorm needs to know nothing about plotting. 
The data structure consists of two vector compo¬ 
nents for the x and y coordinates of the points to 
plot. Once the probability plot is seen as a data 
structure, it is straightforward to use this structure 
for further analysis—by fitting some suitable line to 
the points in the plot, for example. 

The graphical functions are not locked into 
specific devices because both the user-typed expres¬ 
sion and the underlying algorithms are written 
independently of specific graphic devices. Actual 
graphical output is produced through a device 
driver that converts the graphics output, at a 
relatively low level, into commands for a particular 
device (see Figure 2). The commands are passed 
from the function to the device driver by means of a 
set of pipes. Drivers exist for ordinary printing 
terminals and a range of interactive plotting 
terminals. A driver is written by implementing 
routines to carry out a specified set of graphic 
primitives (such as “draw a line” or “plot a 
character”), and by providing a definition of the 
device in terms of basic graphic parameters (for 
example, the device coordinate system or raster 
size). Incorporating a new device typically takes a 
few days or less; the process is straightforward 
enough that users can write their own device drivers 
by following the instructions in Extending the S 
System , by Becker and Chambers (Wadsworth, 
1985). 



Figure 2 — Operation of device-independent graphics. 
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THE S SYSTEM 


S was designed using the model of a 
language operating on complete 
datasets, interactively, in a 
nonsequential manner. 


TOOLS: THE OPERATING SYSTEM 

The complete S system contains about 6000 lines 
of interface language, 35,000 lines of algorithm 
language and 9000 lines of C code. Development 
and maintenance of S by the two of us requires 
efficient use of time. Our experience is that three as¬ 
pects of the design particularly affect human 
efficiency: the languages in which programming is 
done, the tools for maintaining the application 
system, and the operating system interface. 

We developed our own interface language and 
algorithm language. This may have accounted for 
perhaps 10 to 15 percent of our total effort, but this 
development has been cost-effective. Interface 
routines describe arguments to S functions, check 
for errors in arguments, allocate space for data 
structures, call computational routines, and return 
results. If interface routines were written directly in 
a general language like Fortran, they would be 
much more complicated and error-prone, and all 
but the most sophisticated users would find it 
impossible to write their own S functions. During 
compilation, an interface routine typically expands 
into a much larger Fortran routine (representing an 
order of magnitude more lines of source code). Much 
of this expansion reflects inherent clumsiness in 
using Fortran to express the argument processing, 
dynamic storage management, and result genera¬ 
tion encompassed in an S function. At the same 
time, the use of Fortran as an intermediate language 
is important. We could not re-implement all the 
basic computational algorithms previously written 
in Fortran. 

The use of software tools is essential for creating 
and maintaining a system such as S. Compiler- 
compilers, macroprocessors, and more specialized 
tools ease the burden of system development. 
During compilation, the interface language goes 
through our own simple compiler, two passes of the 
M4 macroprocessor, RATFOR, and Fortran. Obvi¬ 
ously, we are not trying to optimize compilation 
time. This multistep process, however, does enable 


us to modify individual steps as our needs change. 

Other tools are used to provide specific utilities 
for S developers. The make system for maintaining 
programs is used to generate the S executive and the 
individual functions. 

For tools to be useful in large applications 
systems, they themselves should be easily adapt¬ 
able. For example, our use of make is highly 
specialized. The interface routines and the support 
programs, whether based on RATFOR or C, all take 
advantage of special S facilities. We therefore 
replace and extend make’s built-in rules for 
compiling to include these special features. The 
result is a customized tool, itself built from a 
number of tools. 

The ease with which tools are put together is also 
a function of the operating system environment. 
The UNIX environment is convenient for developing 
a system such as S, both because of specific 
facilities and because the operating system tries not 
to be unnecessarily restrictive. Facilities such as 
pipes and a flexible command interpreter make the 
creation of customized tools much easier. The 
absence of complex rules about file formats and 
interprocess protocols, on the other hand, has 
meant that our implementation has had fewer 
barriers to scale than it might have otherwise. 

The dependence of the current version of S on its 
operating system environment involves both the 
internal dependencies and the use of operating 
system features in the tools. The dependencies on 
computer hardware , such as machine accuracy, 
are relatively easy to handle. The large majority of S 
code passes through Fortran during compilation. 
Non-portable features, such as the choice of special 
characters and machine precision, are isolated in 
the macroprocessing phase and kept in a single file. 

The use of Fortran as an intermediate language 
and the parametrization of machine-dependencies 
make S source code quite portable. On the other 
hand, implementing and using a system like S 
benefits from a good general computing environ¬ 
ment. The UNIX system has allowed us to combine 
and modify tools to put together S. In a more 
restrictive system, we would have been obliged to 
provide more of the support environment ourselves. 
Perhaps most importantly, the UNIX system is being 
used on a variety of new computer systems, and 
when that is done, S goes along for free. Because of 
this form of portability, S currently runs on 
hardware ranging in size from AT&T’s UNIX PC to 
large IBM mainframes. 

HISTORY 

Work on S began at Bell Laboratories in 1976 and 
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S represents an approach to 
computing that emphasizes the 
effectiveness cf the human as the 
most important design criterion. 


an initial implementation on a large Honeywell 
mainframe system was in use late that year. (This 
was the machine left over after Bell Laboratories 
dropped out of the Mul :ics project.) Starting in 1978, 
a version of S was developed for the UNIX system on 
an Interdata compute-just after the UNIX Seventh 
Edition port was accjmplished on that machine. 
Since 1981, the UNIX-based version of S has been 
distributed outside Bell Laboratories by AT&T. 

When the design of S began, a group of us at Bell 
Laboratories conside-ed the statistical software 
that existed at the time in terms of our goal of good 
data analysis, particjlarly in an interactive, ex¬ 
ploratory environment. We could ascertain three 
main approaches to daing statistics on a computer: 
programming in a conventional language, usually 
Fortran (this had been our own previous approach): 
mainframe statistical packages such as BMD, SAS, 
and SPSS; and a few interactive languages, notably 
APL. We recognized the need for better use of 
human resources than was possible when it was 
necessary for individuals to develop their own 
Fortran applications, but we found problems with 
the existing alternatives to Fortran. 

Statistical packages arose during the 1960s and 
were closely modeled on the idea of sequentially 
processing a series oi records on punched cards or 
magnetic tape. This model has had several bad 
influences. Good dati analysis is highly iterative, 
responding to impo-tant facts observed in the 
analysis itself. Picturing analysis as processing a 
sequence of records through a limited set of 
statistical commands discourages this freewheeling 
interaction with the data. In particular, interactive 
use of the statistical packages was either not 
available or consisted largely of the ability to set up 
the card deck and run it from a terminal. S, on the 
other hand, was designed using the model of a 
language operating on complete datasets, interac¬ 
tively, in a nonsequential manner. A number of 
modern statistical techniques, like robust estima¬ 
tion. cannot easily be expressed in the sequential 


form, and are therefore hard to incorporate in some 
of the packages. 

Another result of the batch approach was the 
tendency to "shotgun” output, printing all the 
summaries likely ever to be relevant from a 
particular model or process. Instead, S tries to 
provide a wide variety of displays, particularly 
graphical, that can be used interactively to see 
summaries relevant to a particular user. Graphics, 
like interaction, was not part of the original design 
of the mainframe packages. Since 1976, many of 
these packages have added graphical facilities, but 
the graphics tend to be viewed as “reports” rather 
than as integral parts of the analysis. For example, 
most of the graphics add-ons do not include graphic 
input, which in our opinion is essential for 
identifying important features observed in the plots. 

The APL language, while not designed for 
statistical computing, offered a very different (and, 
in many ways, more attractive) approach. It was 
intended for interactive use, with users typing 
expressions that operated on whole datasets and 
produced immediate output at the terminal. Users 
can extend the language by defining interpreted 
functions that can then be used in the same way 
that primitive APL operators are. These are all 
features that contribute to APL’s usefulness for data 
analysis, and thus have been incorporated into S. 
The consistency and functionality of APL’s opera¬ 
tors are also present in S; in S, however, such 
operations are normally carried out by functions 
rather than by operators. The main problems with 
APL are its syntax, its data structure, and its 
isolation from other languages. 

S represents an approach to computing that 
emphasizes the effectiveness of the human as the 
most important design criterion, as shown by the 
emphasis on friendly interactive access to comput¬ 
ing, information hiding, and on greater flexibility 
through delayed binding. Our philosophy is that the 
effectiveness of the human is the most important 
criterion for the design of any computer system. 

EXPERIENCE AND EVOLUTION 

A significant contribution to the evolution of S 
has come from user activities and experience. By 
far, the majority of our users are not professional 
statisticians. Instead, they are professionals in 
other areas who have a need for data analysis, 
graphics, or other S facilities to enhance their own 
work. In a number of cases, their specialized use of S. 
has led them to develop, in effect, unique systems 
for their own specific user communities. This is 
usually done by creating a set of S macros to 

Continued to Page 100 
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UNIX IN REAL TIME 


What it takes to make the grade 


by Clement T. Cole and John Sundman 
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As UNIX has moved from the 
orld of computer science re¬ 
search into The Real World , its 
character has been altered. This 
*ticle explores some of the modi- 
^ations that have been made to 
support “real-time” processing 
id looks at a number of the 


demands that real-time applica- 


e\ 

th; 


ms make of the operating sys¬ 
tem. 

Real-time operating systems 
cdn be described in terms of 
seven requirements. It is our 
contention that UNIX, suitably 
modified, can fill all seven. Before 
listing these requirements, how- 
er, it’s important to understand 
at they stem from applica¬ 
tions—which, unlike UNIX, have 
standard definition. (Admit- 
dly, the /usr/group UNIX In- 
dace Standard published in 
arch, 1984, has its detractors, 
but the IEEE PI003 Portable 
Operating System Environment 
irking Group has started work 
a better definition.) 

Because real-time applications 
la<fck a standard definition, this 


no 

te 

te 

M 


W 

or 


■v ■ 

article makes a distinction be¬ 
tween a real-time monitor and 
a real-time operating system. 
Even though our distinction is 
not rigorous, we feel it is impor¬ 
tant to make if we are to avoid 
comparing apples with oranges. 
To this end, we have restricted 
our comments to applications 
that require an operating system. 
We make no claims for the suit¬ 
ability of UNIX as a real-time 
monitor. 

The class of real-time applica¬ 
tions that interests us includes 
the problems that traditionally 
have been managed by systems 
like Digital Equipment Corpora¬ 
tion’s RSX and VMS; Data Gen¬ 
eral’s RDOS, MP/AOS, and AOS/ 
RT-32; and Hewlett-Packard’s 
MPE. Our list of seven require¬ 
ments comes from an analysis 
of the traits common to these 
and other similar systems. This 
seems fair since real-time appli¬ 
cations and operating systems 
have been around for a long 
time—longer, certainly, than the 
UNIX system has. Thus, when we 









REAL-TIME UNIX 


state that a real-time operating 
system needs multiple process¬ 
es and quick communications 
among them, we are simply fol¬ 
lowing a long tradition—not de¬ 
fining the problem in terms of a 
ready solution. We make this 
point because UNIX has gotten 
something of a “bum rap” with 
regard to its suitability for real¬ 
time applications. 

For example, in a recent issue 
of Computer Design , three real¬ 
time experts—Bill Allen, Collin 
Hunter, and Bernard Mushin- 
sky—flatly state “Real Time 
Unix is not a good idea.”[13] The 
accusation is often made that 
UNIX devotees see UNIX as the 
solution to every problem, and 
describe these problems in terms 
of solutions already built into 
UNIX. This simply is not the case. 

WHAT IS A 
REAL-TIME SYSTEM? 

Let’s look at what a real-time 
system is. There are two parts to 
consider: a controlled system 
and a controlling system. The 
“controlled system” consists of 
hardware—such as the sort one 
might use for a process in a 
factory or an experiment in a 
laboratory. The “controlling sys¬ 
tem” refers to the computing 
resources—hardware and soft¬ 
ware—that accept and analyze 
data from the controlled system. 
The controlling system some¬ 
times produces data to modify the 
controlled system. 

A real-time operating system, 
like Digital’s VMS or MASS- 
COMP’s Real Time UNIX (RTU) is 
the nucleus of the software used 
by a controlling system. As such, 
the operating system must con¬ 
tain and present to application 
programs the primitives needed 
to build real-time applications. 
An application must be able to 
instantaneously record, analyze, 
and respond to the raw data and 
events produced by the control- 


UNIX has gotten 
something of a "bum 
rap" with regard to Its 
suitability for real-time 

applications. 


ling system [2]. Note that “instan¬ 
taneous” is a relative term and 
that applications described as 
such must be controlled (more 
about this later). 

Requirements Jor a Real- 
Time Operating System. Real¬ 
time operating systems can be 
described in terms of seven fea¬ 
tures: 

1) Support for the creation, dele¬ 
tion, and scheduling of multi¬ 
ple “processes” or indepen¬ 
dent tasks, each of which 
monitor or control some por¬ 
tion of a total application. 

2) Communication “channels” 
between processes to allow 
small amounts of data to be 
sent or received, thus allowing 
two or more related processes 
to share low-volume informa¬ 
tion. 

3) Data “pooling” or sharing, al¬ 
lowing two or more processes 
to pass and examine large 
amounts of data efficiently. 

4) Synchronization between pro¬ 
cesses in an application. 

5) The ability to quickly, reliably, 
and predictably maintain large 
amounts of data in long-term 
backing store. 

6) Synchronization with external 
events. 

7) “Instantaneous” and predict¬ 


able response to external 

events. 

Every real-time system em¬ 
bodies these features to a greater 
or lesser extent. This article at¬ 
tempts to show that standard 
UNIX, with only minor changes, 
embodies the first five features on 
the list. With some other signifi¬ 
cant changes—which already 
have been made in specific in¬ 
stances—the remaining two fea¬ 
tures can also be provided. 

A Word on Monitors. A real¬ 
time monitor is a small, generally 
PROM-based set of subroutines 
dedicated to a unique, limited 
task (an “application” program). 
Monitors , real-time or otherwise, 
are most often shipped with a 
“single-board computer” so as to 
allow an application program to 
operate the module as soon as 
power is applied. Often, an appli¬ 
cations programmer will not re¬ 
place a monitor, but instead use it 
as a starting point, making sub¬ 
routine or “monitor calls” to it in 
order to obtain additional func¬ 
tionality. Monitors thus can limit 
the amount of new code that must 
be written. 

Note, for example, a “smart” 
Ethernet controller such as the 
Excelan EXOS-201 or the Com¬ 
munications Machinery ENP-30. 
Each in itself is a real-time sys¬ 
tem containing an independent 
16-bit processor, memory, and 
I/O hardware. Both can serve 
as a controller for the Ethernet 
and host interface hardware. A 
small, on-board real-time moni¬ 
tor schedules each portion of the 
networking task, responds asyn¬ 
chronously to external events 
(such as the receipt of a packet 
from the wire), recovers from 
errors, and performs the normal 
operations of setting up and 
breaking down network connec¬ 
tions. The controller must per¬ 
form all of these tasks in real 
time. 

A monitor has no concept of 
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long-term data retention to a 
backing store. Neither does it 
concern itself with providing a 
user interface by way of a com¬ 
mand executive, or with running 
a number of independent pro¬ 
grams invoked by system “com¬ 
mands”. A monitor houses on a 
single embedded task that can be 
performed simply and efficient¬ 
ly—like the management of an 
Ethernet controller. 

We place “custom real-time 
operating systems’ , such as 
Hunter and Ready’s VRTX or 
Industrial Programming’s MTOS, 
in the class of PROM-resident 
monitors since they don’t offer all 
the services of full operating sys¬ 
tems. Embedded systems (Ether¬ 
net controllers and the like) are 
often best implemented with 
dedicated monitors. Such moni¬ 
tors do not have to provide a file 
system, a command system, or 
any of the other features one 
would expect in a full operating 
system. 

The key difference between a 
full operating system and a moni¬ 
tor is scale. As Jim Ready (of 
Hunter and Ready) has been 
quick to note, many UNIX ven¬ 
dors embed real-time monitors 
deep inside their smart control¬ 
lers [7). If you define a real-time 
application as one that can re¬ 
spond to raw data and events, you 
might include monitors. But real¬ 
time applications £s we define 
them must accommodate a wide 
range of activities (often involving 
several processors), and must be 
adaptable to large-scale changes, 
even while analyzing and record¬ 
ing data. This is why we have 
excluded monitors irom our dis¬ 
cussion. The services they are 
designed to provide simply do not 
compare to the wealth of services 
supplied by UNIX. 

A Data General MV-8000, 
Hewlett-Packard 3000, MASS- 
COMP MC-5500, cr DEC VAX 
system could be us*d for analog 


Originally, UNIX was 
not written as a "real- 
time" system but as a 
"timeshared" system 
for interactive use. 


data acquisition and encapsula¬ 
tion. An MC-5500 running RTU, 
for example, can gather up to one 
million 16-bit samples per second 
from a controlled system, record¬ 
ing the data in a disk file. As the 
data is gathered, the system can 
perform sophisticated analysis. 
For instance, a user might push 
data through an array processor 
or floating point unit with com¬ 
plex arithmetic subroutines such 
as fast Fourier transforms (FFTs) 
and linear regressions. The inter¬ 
preted result then could be dis¬ 
played in real time on a bit¬ 
mapped graphics display screen. 
Real-time monitors simply are 
not designed to provide this scale 
of service. 

STANDARD UNIX 
AND REALTIME 

What is Standard UNIX? For 
the purposes of this discussion, 
let us assume that “standard 
UNIX” means the system call 
interface as defined by the March, 
1984, /usr/group UNIX Standard. 
We will cite any UNIX features not 
defined by the standard. 

The Real-Time Issue. Origin¬ 
ally, UNIX was not written as a 
“real-time” system (9) but as a 
“timeshared” system for interac¬ 
tive use. This timesharing heri¬ 
tage is responsible for much of 
the denigration that real-time 
UNIX systems suffer today. But if 


one looks at a “timeshared” sys¬ 
tem as a “real-time” system, 
where “instantaneous” response 
is measured in seconds rather 
than milliseconds, one might find 
that UNIX actually has most of 
the seven features required by 
real-time data-acquisition ap¬ 
plications. 

Creating , Deleting, and Sched¬ 
uling Processes. The support 
UNIX offers for process creation, 
deletion, and scheduling is em¬ 
bodied in four simple yet powerful 
system calls: 

• fork(2) creates new processes. 

• exec(2) starts the execution of a 
different program image. 

• wait(2) keeps one process on 
hold until another process is 
completed. 

• exit(2) terminates a process. 

The UNIX kernel schedules 
which process may execute at any 
instant; this function is funda¬ 
mental to system operation. The 
code that handles it is called the 
scheduler. Although the standard 
UNIX scheduler is tuned for time¬ 
sharing use, it provides one con¬ 
cession for real-time applica¬ 
tions—a ’’priority value” that 
can be manipulated with the nice 
command. 

Of the processes in primary 
memory, some wait for an event 
(for example, I/O or the termina¬ 
tion of a child process), while 
others stand ready to continue 
execution at any time. Associated 
with each process is a priority 
that determines the order in 
which processes will run. 

The priority of all operating 
system processes—including the 
operating system portion of us¬ 
er processes (system calls)—is 
greater than that of user jobs. 
Among these system tasks, disk 
I/O has a high priority, terminal 
I/O a low priority, and time-of-day 
events an even lower priority. 
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User-process priorities are as¬ 
signed by an algorithm that 
weighs the amount of compute 
time consumed by a process 
against the amount of real time 
that’s used. A process that has 
devoured a lot of compute time in 
the last real-time unit is assigned 
a low user priority. Because inter¬ 
active processes are character¬ 
ized by low ratios of compute-to- 
real time, interactive response is 
maintained without special ar¬ 
rangements. 

The scheduler simply selects 
the process with the highest pri¬ 
ority, thus picking system pro¬ 
cesses over user processes. The 
compute-to-real-time ratio is up¬ 
dated every second. Based on 
these results, high-priority pro¬ 
cesses are allowed to preempt 
low-priority processes—even if 
the low-priority processes already 
are running. Further, the sched¬ 
uling algorithm has a negative 
feedback character: if a process 
uses its high priority to monopo¬ 
lize computing resources, its pri¬ 
ority will drop. Similarly, if a low- 
priority process is ignored for a 
long time, its priority will rise. 

Although the priority of a pro¬ 
cess is calculated by internal 
operating system algorithms, the 
user or programmer can make a 
contribution to this calculation 
by assigning a nice value to a 
process. This value is set by using 
the nice(l) command, which in 
turn uses the nice(2) system call. 
The default nice value for all 
processes is 0. Conventionally, 
this value is allowed to range 
between 0 and 19. The higher it 
is, the lower the resulting priority. 
However, nice values alone are 
not sufficient to guarantee static 
priority scheduling. 

Communications Channels. 
The pipe, a simple, elegant chan¬ 
nel for communication between 
two processes, is one of the most 
celebrated innovations offered by 
UNIX. The pipe(2) system call 


Modifications have 
been made by 
countless unsung 
heroes in a myriad of 
UNIX installations. 


offers a method for creating 
a simple read/write communica¬ 
tions channel between two pro¬ 
cesses. The Jifo (or named pipe), 
operates in a similar manner, but 
does not require that the two 
communicating processes be part 
of the same process family tree. 
These two primitives allow two or 
more processes to send low-band¬ 
width information back and forth 
by read and write operations on 
the pipe. 

Newer implementations of the 
UNIX system contain communi¬ 
cations primitives that supple¬ 
ment pipes. The System V IPC 
and the 4.2BSD socket mecha¬ 
nisms are instances. These are 
usually used for networking, so 
they are not discussed at length 
here. But they are, of course, 
available for real-time program¬ 
ming. 

Data Pooling. Data pooling 
allows large amounts of data to be 
shared between or among pro¬ 
cesses. This can be accomplished 
by opening a file for access by a 
number of processes, and also 
by overlapping (sharing) the da¬ 
ta segments (memory address 
ranges) of different processes. 
The shared memory technique is 
adaptable for real-time use. 

Shared memory has been of¬ 
fered in a number of schemes. In 
System V, AT&T provides for it 
with the shmop(2) primitive. This 


mechanism allows large amounts 
of data to be accessed by more 
than one process at a time. 

Synchronization Between Pro¬ 
cesses. The signal is the tradi¬ 
tional UNIX tool for synchroniz¬ 
ing activities in two processes; it 
allows one process to notify an¬ 
other of an event. The signal(2) 
call provides a software interrupt 
mechanism analogous to a hard¬ 
ware interrupt. Any process can 
send one or more signals to any 
other process so long as the 
sending process knows the pro¬ 
cess id of the destination process 
[9]. A process that expects to 
receive a signal should include a 
routine (signal handler) that can 
be called whenever a signal ar¬ 
rives. Certain signals, such as the 
alarm(2) timer signal, can be sent 
by the system itself. 

The semop(2) (semaphore op¬ 
eration) primitives of AT&T’s re¬ 
leases offer another scheme for 
synchronizing processes. These 
primitives provide a mutual ex¬ 
clusion mechanism by using a 
semaphore operation between 
multiple processes, and are often 
used in conjunction with the 
shared memory (shmop(2)) calls. 
The semop(2) calls enable coordi¬ 
nation between processes that 
may attempt to write into the 
common data pool at the same 
time. 

Reliable Data Transfer to 
Backing Store. Reliable data 
transfer to long-term backing 
store is usually implemented as a 
file system on disk. The celebrat¬ 
ed UNIX hierarchical file system 
and sophisticated file system util¬ 
ities represent a higher level of 
functionality than is strictly re¬ 
quired by many real-time applica¬ 
tions. A simple real-time system 
only needs to provide the ability to 
open, read, and write files— 
albeit quickly. Real-time applica¬ 
tions that perform data logging 
should spend as little time as 
possible interacting with the file 


64 UNIX REVIEW NOVEMBER 1985 









system since their p 'imary job is 
to interact with the system they 
are controlling. The necessary 
backing store capabilities are 
provided by the UNIX calls 
open(2), read(2), and write(2). 

NON-STANDARD 
REAL-TIME ENHAIJCEMENTS 

Having described the features 
in standard UNIX that are well 
adapted, or adaptable, for use in 
real-time applicatic ns, we find 
that only two items are missing 
from our list of seven real-time 
requirements— synchronization 
of processes with external events, 
and predictable and “instan¬ 
taneous” response to external 
events. The rest o' this article 
discusses how UN X has been 
enhanced and reworked to pro¬ 
vide these features. By “en¬ 
hanced” we refer to modified 
features already ii UNIX. By 
“reworked” we refer to entirely 
new features that have left the 
UNIX system’s original function¬ 
ality in place. 

We hope it is unde rstood that to 
make UNIX faster (an implied 
requirement of any *eal-time sys¬ 
tem), developers must find and 
replace inefficient code. Many 
parts of the UNIX kernel and a 
fair number of the system’s utili¬ 
ties were never designed to be 
used as they are today: thus their 
original “tuning” no longer ap¬ 
plies. Over time, many of these 
inefficiencies have been over¬ 
come and much cods has been re- 
tuned. These modiiications have 
been made by countless unsung 
heroes in a myriad cf UNIX instal¬ 
lations, but we cannot delve into 
the details here. Instead, we refer 
you to the proceedings of the 
various Usenix conferences ot the 
last 10 years. 

Creating , Deletirg. and Sched¬ 
uling Processes. Ch anges made in 
this area focus on he scheduler. 
The scheduler is usually the first 
thing to be modified when UNIX is 


tuned for real-time use. That’s 
because most implementations of 
UNIX use a scheduler that has 
been tuned to a timesharing load. 
Timesharing embodies a notion 
of fairness—each process should 
be given its proportionate slice 
of the available computing re¬ 
sources. Real time, though, is 
autocratic: some processes are 
more equal than others. The most 
equal of the lot are not only given 
the better part of the system’s 
resources, they also must be 
guaranteed that processing re¬ 
sources will be available to them 
at any instant. (Other real-time 
operating systems have employed 
the concept of sub-process , or 
task, to provide a flexibility in 
scheduling that does not incur 
the overhead of context switches. 
However, no UNIX vendor of 
which we’re aware has chosen 
this approach—although it has 
appeared in academic incarna¬ 
tions.) 

Imagine, for example, an ap¬ 
plication that monitors the life 
functions of a cardiac patient. 
The routine sampling application 
might take an interrupt every few 
seconds to monitor changes in the 
patient’s temperature. If a critical 
event—such as apnea —were to 
occur, though, the application 
might need to immediately dis¬ 
able temperature monitoring and 
start monitoring and responding 
to data returned from cardiac 
sensors. A second or even a tenth 
of a second might be too long to 
wait. 

To enhance the UNIX schedul¬ 
er, the RTU operating system has 
introduced the concept of real¬ 
time priorities. Processes with 
real-time priorities are selected to 
run before processes without 
such priorities. A real-time prior¬ 
ity is established by setting a nice 
value in the range -11 to -20. 

Real-time processes under this 
scheme do not have their priori¬ 
ties updated by the scheduler as 


normal processes do: instead, 
they are assigned a fixed priority. 
These processes do not incur 
scheduling penalties, regardless 
of whether they monopolize pro¬ 
cessor time or not. It thus is 
possible in a timesharing envi¬ 
ronment to run a process that 
performs some service at a reli¬ 
ably high priority whenever the 
need arises. One example of 
where this might be useful is in 
the service of a serial line or a 
graphics processor. If two or more 
real-time processes are in mem¬ 
ory with the same priority, they 
will run on a Jlfo basis. 

Modifications to the scheduler 
by no means offer the only solu¬ 
tion. Charles River Data Systems 
(CRDS), for instance, has re¬ 
placed the entire “bottom half” of 
UNIX with proprietary software 
better suited to real-time use. The 
user and programmer operate in a 
UNIX paradigm, but the internal 
implementation of the system is 
“home-grown”. The CRDS oper¬ 
ating system, called UNOS, looks 
like UNIX but supports a notion of 
“process” in both the kernel and 
user memory space. The inter¬ 
nals of UNOS are governed by the 
use of eventcounts [8], and the 
CRDS system employs a schedul¬ 
er built around this primitive. 
The result is a natural cooper¬ 
ation between different processes 
in which real-time response can 
be easily attained [3]. 

Communications Channels. 
Pipes were originally implement¬ 
ed as a special type of disk file. 
This made sense on the PDP-11 
architecture where UNIX was ori¬ 
ginally implemented. In that fam¬ 
ily of machines, memory was 
limited, making use of the disk for 
pipes worthwhile but slow. As 
UNIX migrated to large-memory 
architectures such as the VAX 
and the Motorola MC68000 fam¬ 
ilies, use of disk for pipes became 
less important. Thus, to speed the 
performance of pipes in real-time 
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systems, some UNIX variants im¬ 
plement pipes in memory. 

Data Pooling. An important 
problem (from a user program’s 
point of view) with the current 
UNIX implementation is its use of 
memory management; program¬ 
mers may require the ability to 
manipulate cache (if the system 
has one) as well as to control 
those portions of an application 
locked into system memory. 

In most high-performance ma¬ 
chines, both an address and a 
data cache are used to keep the 
processor running at full speed. 
When memory is shared, it may 
be necessary to disable the cache 
on shared pages. Thus, a user 
program must have some way of 
informing the system that shar¬ 
ing is in effect. 

MASSCOMP’s solution was to 
supply two system calls, (pinfo(2) 
and cinfo(2)), that allow a user to 
examine main memory use. Other 
manufacturers have implement¬ 
ed similar calls. Since there is not 
yet a standard for this type of 
operation, programmers should 
be aware that each manufacturer 
does it differently. 

Another problem with memory 
access is its tendency to make 
system response less predictable. 
Virtual memory systems are of¬ 
fered on most modern computers, 
including the MASSCOMP MC- 
5000, Apollo DN, and Digital VAX 
series. Virtual memory is conven¬ 
ient for programming but it 
wreaks havoc on the “predictabil¬ 
ity” of a program. In most real¬ 
time applications, the program¬ 
mer wishes to guarantee that at 
least the key parts of a process 
have been locked into memory. 

Version 7 UNIX contains a 
facility to allow memory locking, 
but this feature was dropped until 
System V brought it back— 
meaning that a large number of 
UNIX implementations current¬ 
ly are lacking. Implementations 
that stress real-time have had to 


Another problem with 
memory access is its 
tendency to make 
system response less 
predictable. 


reinstate this facility or move to 
System V. MASSCOMP’s RTU, for 
instance, provides the plockin(2) 
and unplock(2) calls for this 
purpose. 

It should be noted, however, 
that these are “dangerous calls” 
for a couple of reasons. In the first 
place, as more memory is locked 
down, less is left available for 
general use. What is worse, mem¬ 
ory deadlock problems can occur 
that prevent processes that re¬ 
quire memory from proceeding 
until segments are unlocked. Ob¬ 
viously, a deadlock can destroy 
the performance of a system or 
can shut the system down alto¬ 
gether. In a dedicated real-time 
situation, the programmer should 
calculate the amount of mem¬ 
ory needed and make sure that 
the machine contains “enough” 
physical memory to allow the 
application to be “locked” with¬ 
out causing a deadlock. 

Only the system designer can 
determine what the value of 
“enough” is for any application. 
The operating system can enforce 
quotas but cannot, of itself, guar¬ 
antee performance. 

Synchronization Between Pro¬ 
cesses. UNIX signals are used in a 
software interrupt scheme origin¬ 
ally modeled around the concept 
of hardware exceptions. Proces¬ 
sors generate “hardware excep¬ 
tions” when they receive instruc¬ 


tions they cannot perform, such 
as a division by zero exception. 
Signals were provided so that 
programmers could implement 
exception handlers to allow “or¬ 
derly termination” if a hardware 
event occurred. Signals were later 
extended to allow for a few other 
‘‘software exceptions”, such as 
an interrupt generated by a termi¬ 
nal interrupt key, like CTRL-C or 
DELETE. 

In standard UNIX, signals are 
implemented on a process-by¬ 
process basis. Each process typi¬ 
cally has 16 or more signals that 
can be handled (“caught”) inde¬ 
pendently. (At least one signal is 
not capable of being “caught” by 
the process. This is the termina¬ 
tion signal used to abnormally 
exit and terminate a process with 
extreme prejudice.) Most recent 
UNIX systems implement more 
than 16 signals per process, in¬ 
cluding at least one reserved for 
the user. 

Signals are used for synchroni¬ 
zation, but they have flaws: 

• First, they can be lost. It is 
possible for a process to block 
out signals. If a signal arrives 
under these conditions, it never 
will be received. Signals some¬ 
times are blocked for short per¬ 
iods to ensure uninterrupted 
execution of portions of a pro¬ 
gram. But the loss of a signal 
that represents a critical event 
clearly cannot be tolerated. 

• Second, signals cannot be as¬ 
signed a priority. In most real¬ 
time situations, certain events 
are more critical than others, 
and must accordingly be as¬ 
signed a higher priority. 

• Finally, only a finite number of 
signals can be assigned to any 
one process. Depending on the 
UNIX implementation, the num¬ 
ber of available signals may be 
too small for the real-time appli¬ 
cation at hand. 
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Many implement Drs of UNIX 
have “fixed” signals. The Berke¬ 
ley signal package in 4.2BSD 
provides a case in point. However, 
the Berkeley package has prob¬ 
lems of its own. In “fixing” sig¬ 
nals, the Berkeley developers lost 
many of the original UNIX signal 
semantics. They thereby broke a 
lot of code. Indeed, as Henry 
Spencer of the University of To¬ 
ronto so eloquently stated recent¬ 
ly: “4.2BSD does everything 
UNIX does, . . .only differently.” 
[ 12 ] 

MASSCOMP has taken a differ¬ 
ent tack on the signals issue. In 
RTU Version 3.0, lour different 
event packages were implement¬ 
ed: three UNIX sigrals packages 
(a “standard” Version 7/System 
Ill/System V package, a Berkeley 
4.1 package, and a Berkeley 4.2 
package) and a new package 
designed for real-time applica¬ 
tions based on the asynchronous 
system trap (AST). 

Since the AST is not closely 
related to anything in classical 
UNIX, we describe it under a 
separate heading. 

The Asynchrorous System 
Trap. The concept of an asyn¬ 
chronous system trap, or AST, 
first appeared in Digital Equip¬ 
ment Corporations RSX and 
VMS operating systems [1]. As 
implemented in MASSCOMP’s 
RTU, an AST is a SDftware inter¬ 
rupt that remedies the defects of 
signals. 

ASTs have programmer-speci¬ 
fied priorities, and are queued by 
the operating system. Delivery of 
ASTs is guarantee!, and occurs 
in order of priority. In addition, 
each AST handler :an be passed 
a parameter when the AST is 
delivered. Parameters are used 
to distinguish between different 
events and often serve as pointers 
to memory structures. 

As with signals, a process that 
expects to receive a certain AST 
must set up an AST handler in its 


process space. The handler is a 
subroutine called asynchronous¬ 
ly during the normal processing 
of the program. When called, the 
subroutine runs as part of the 
user process and thus has access 
to all operating system capa¬ 
bilities. 

ASTs are available systemwide 
(rather than being open to only a 
few select processes). The num¬ 
ber of ASTs available is deter¬ 
mined by the system manager 
when the system is built. 

Predictable Transfer of Data 
to Backing Store. Real-time data 
acquisition systems often require 
more throughput to disk than is 
possible under standard UNIX. 
Most UNIX system implemen¬ 
tations, even those that use 
the Berkeley fast file system , 
must map large sections of data 
to different parts of the disk. 
The UNIX system disk-buffering 
scheme generally does an excel¬ 
lent job of caching file-mapping 
blocks. This means that the over¬ 
head of file-mapping seldom in¬ 
volves an additional physical disk 
read. Even so, its file system 
overhead may be too great for 
some real-time applications. 

In such cases, one traditional 
approach has been to implement 
“contiguous files” by allocating 
contiguous disk sectors to a single 
file. This has the net effect of 
improving file system through¬ 
put. Beyond this, it is desirable to 
reduce all overheads to a mini¬ 
mum so as to write data to disk at 
the highest speeds possible. One 
approach is to implement a high¬ 
speed data-to-disk mode that 
grants a single process exclusive 
access to the disk. In this mode, 
the system locks out all other 
accesses to disk, thus eliminating 
latency for any additional seeks. 

Many UNIX implementations 
support “raw disk partitions” 
that can be exploited in much the 
same way that contiguous files 
are. Contiguous files, though, 


generally provide a more flexible 
way to allocate contiguous disk 
blocks than does the partitioning 
of a physical disk at system 
generation time. 

The substitution of a bit map 
for the UNIX free list is another 
simple efficiency that has ap¬ 
peared in real-time system imple¬ 
mentations (as well as a few 
timeshared UNIX versions). On 
most UNIX file systems, the free 
list [10] points to free blocks that 
can be written by user processes. 
Searching this list, though, is a 
slow task: a bit map containing 
the same information can be 
inspected more quickly. A bit map 
is necessary when contiguous 
files are implemented because it 
represents the easiest way to find 
large contiguous space. An inter¬ 
esting side effect is that a “free- 
block bit map” uses less disk 
space than the standard UNIX 
free list. 

Another major change that can 
be made to the “standard” UNIX 
file system makes logical disk 
block size a function of each 
mounted file system rather than a 
built-in system parameter. This 
allows for increased file through¬ 
put by using a relatively large 
block size on large disks (at the 
cost of some space lost due to 
fragmentation), while using a 
smaller block size on floppy 
disks, where space utilization is 
more critical. 

The Missing Two Require¬ 
ments. An earlier comparison 
made between UNIX features and 
our list of seven real-time require¬ 
ments showed only two items 
missing—the synchronization of 
processes with external events, 
and the predictable, “instanta¬ 
neous” response to external 
events. As it turns out, these two 
features naturally fall out of work 
providing the other five features. 
In MASSCOMP’s RTU, for exam¬ 
ple, external events can generate 
Continued to Page 101 
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A routine check 

by Bill Freiboth and Bill Tuthill 


How can a piece oj code 
that is an order of magni¬ 
tude too large be consid¬ 
ered reliable? There is that 
much more that must be un¬ 
derstood in order to make 
changes. Library functions 
. . .are one way to reduce 
the apparent complexity oj 
a program; they help to 
keep program size manage¬ 
able. and they let you build 
on the work of others, 
instead oj starting from 
scratch each time. 

Kernighan and Plauger. 

The Elements of 
Programming Style 

Anyone who peruses old UNIX 
code is shocked by the sheer 
number of instances where pro¬ 
grammers obviously have coded 
their own functions in preference 
to using common library rou¬ 
tines. Especially prevalent are 
private string-handling routines 
which are analogous to strcpyQ 
and strcmp(). One reason for this 
is that many UNIX programs were 
written before such library rou¬ 
tines became available. Another 
is that the UNIX system contin¬ 
ues to grow, making it difficult to 
keep up with all the new library 
functions that appear. To counter 
this trend, we offer a comparison 
of the library routines available 
on Version 7, System V, and 
4.2BSD. 



Several years from now, we will 
look back on today’s UNIX soft¬ 
ware with a jaundiced eye. No 
doubt, we will be surprised to see 
custom binary search algorithms, 
tree management routines, and 
record locking schemes despite 
the fact that perfectly good library 
routines already exist for these 
purposes. The System V Inter¬ 
face Definition, for example, in¬ 
cludes specifications for each of 
these routines. 

There are good reasons to use 
library routines in preference to 
“rolling your own”. First, pro¬ 
grams are easier to understand 
and maintain when other pro¬ 
grammers are already familiar 
with—and can trust—calls to 
library routines. Second, library 
routines are often faster than 
hand-coded functions because of 
library optimizations. Some ven¬ 


dors, for example, deliver vastly 
improved versions of mallocQ 
and the Standard I/O Library. 
Third, library routines are main¬ 
tained by other people, and 
changes can be coordinated with 
those made to other parts of the 
system—meaning that you effec¬ 
tively have use of a maintenence 
staff not on your payroll. Finally, 
library routines are documented, 
and actually do get improved. 
While documentation may be im¬ 
perfect, it is read frequently, and 
is likely to be improved in future 
releases. Private versions of func¬ 
tions tend to be undocumented 
and hidden in specific programs, 
waiting to surprise users when¬ 
ever new releases of the operating 
system are installed. 

As is evident from the table 
accompanying this article, Sys¬ 
tem V has the most library rou¬ 
tines, with 4.2BSD placing a 
distant second. More than half of 
the System V additions were actu¬ 
ally part of System III, but they 
are credited to System V since 
many users did not install System 
III. The curses screen handling 
functions, and the termlib or 
termcap library routines are list¬ 
ed as one-line items. Both have 
been discussed in this column 
before. Future columns will dis¬ 
cuss library routines available 
only on System V or 4.2BSD. 

The C compilers on System V 

Continued to Page 73 
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Availability of Library Routines 

Routine 

V7 

Sys V 

4.2 

Comment 

C Library 





a64l() 


X 


convert base 64 AS CM string to long integer 

abort() 

X 

X 

X 

create a program fault 

asctimej) 

X 

X 

X 

convert a time zone data structure to string format 

atof() 

X 

X 

X 

convert character string to floating point 

atoi() 

X 

X 

X 

convert character string to integer 

atol() 

X 

X 

X 

convert character string to long integer 

bcmp() 



X 

compare a byte array 

bcopy(| 



X 

copy a byte array 

bzero() 



X 

zero a byte array 

bsearchf) 


X 


binary table search routine 

calloc() 

X 

X 

X 

allocate an initialized array space 

clock() 


X 


obtain process CPU time 

crypt)) 

X 

X 

X 

encrypt a password using setkey and encrypt 





functions 

ctime() 

X 

X 

X 

convert date and time to string format 

ecvt() 

X 

X 

X 

convert floating point to string format 

encryptf) 

X 

X 

X 

encrypt a key using the DES algorithm 

endgrentf) 

X 

X 

X 

end group file processing 

endpwent() 

X 

X 

X 

end password file processing 

endutent() 


X 


end processing of the accounting file 

fcvtO 

X 

X 

X 

convert floating point to Fortan F string format 

free() 

X 

X 

X 

free an allocated storage block 

frexp() 

X 

X 

X 

split a number into mantissa and exponent 

ftok() 


X 


construct access key for IPC using msgget, semget 





and shmget facilities 

ftw() 


X 


descend a directory hierarchy and apply a user- 





supplied function to each node 

gcvt{| 

X 

X 

X 

convert floating point to Fortran F or E string format 

getcwd() 


X 


obtain the current directory name in string format 

getenv() 

X 

X 

X 

obtain values for process environment variables 

getgrent)) 

X 

X 

X 

read group file entries sequentially 

getgrgid() 

X 

X 

X 

read group file entries by group ID 

getgrnam() 

X 

X 

X 

read group file entries by group name 

getlog in() 

X 

X 

X 

obtain a pointer to a user login name entry 

getoptO 


X 


obtain command line options 

getpassO 

X 

X 

X 

read a password from a terminal without echoing 

getpwO 

X 

X 

X 

obtain a user name from a user ID 

getpwent() 

X 

X 

X 

read password file entries sequentially 

getpwnam() 

X 

X 

X 

read password file entries by group name 

getpwuid() 

X 

X 

X 

read password file entries by group ID 

getutent() 


X 


read accounting file entries sequentially 

getutid() 


X 


search an accounting file by type 

getutlinef) 


X 


search an accounting file by device 

gmtime() 

X 

X 

X 

obtain a time data structure containing the GMT time 

gsignalf) 


X 


send a signal to a process or a group of processes 

hcreatef) 


X 


create a hash-table 

hdistroy() 


X 


remove a hash-table 

hsearchf) 


X 


search for an entry in a hash-table 

initgroups)) 



X 

initialize group access list 

irand48() 


X 


return double precision random numbers from 0.0 to 

1.0 

isalnum() 

X 

X 

X 

test for alphanumeric character 

isalphaf) 

X 

X 

X 

test for alphabetic character 

isascii() 

X 

X 

X 

test for ASCII character 

isattyd 

X 

X 

X 

test whether a file is associated with a terminal 
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Routine 

V7 

Availability of Library Routines 

Sys V 4.2 Comment 

C Library (continued/ 





iscntrl)) 

X 

X 

X 

test for control character 

isdigit() 

X 

X 

X 

test for digit character 

isgraph() 


X 


test for printable character excluding spaces 

islower() 

X 

X 

X 

test for lower case character 

isprint() 

X 

X 

X 

test for printable character 

ispunct() 

X 

X 

X 

test for punctuation character 

isspace)) 

X 

X 

X 

test for white space character 

isupper)) 

X 

X 

X 

test for upper case character 

isxdigit)) 


X 


test for hexadecimal format data 

jrand48() 


X 


return long integer random numbers from -2 3 ' to 

731 

krand48() 


X 


return double precision random numbers from 0.0 to 
i n 

l3tol() 

X 

X 

X 

convert from 3 byte integers to long integers 

I64a() 


X 


convert long integer to base 64 ASCII string 

ldexp() 

X 

X 

X 

combine mantissa and exponent 

localtime)) 

X 

X 

X 

obtain a time data structure adjusted for local time 

longjmpO 

X 

X 

X 

restore stack environment information 

Irand48() 


X 


return long integer random numbers from 0 to 2 31 

Isearch)) 


X 


linear table search and update routine 

Itol 3() 

X 

X 

X 

convert from long integers to 3 byte integers 

mallocf) 

X 

X 

X 

allocate a storage block 

memccpyO 


X 


copy memory stopping after a specified character 

memchr() 


X 


search memory for characters 

memcmpd 


X 


compare memory locations lexicographically 

memcpyO 


X 


copy memory to memory 

memset() 


X 


initialize memory to a constant value 

mktempd 

X 

X 

X 

make a unique file name using a template 

modf() 

X 

X 

X 

split mantissa into integer and fraction 

monitor)) 

X 

X 

X 

prepare execution profile for a program 

mrand48() 


X 


return long integer random numbers from -2 31 to 

731 

nlist)) 

X 

X 

X 

4 

get entries from an executable file's symbol table 

nrand48() 


X 


return long integer random numbers from 0 to 2 31 

perror)) 

X 

X 

X 

produce error messages using standard output 

pkopen)) 

X 



packet driver simulator 

putpwent)) 


X 


write a password file entry 

pututline)) 


X 


write accounting file entries 

qsort)) 

X 

X 

X 

quicker sort algorithm 

rand)) 

X 

X 

X 

obtain successive pseudo random numbers range 





(0,32767) 

random/) 



X 

better random number generator than rand)) 

realloc)) 

X 

X 

X 

change the size of a storage block 

setgrent)) 

X 

X 

X 

reposition to the start of the group file 

setjrnp)) 

X 

X 

X 

save stack environment information 

setkey)) 

X 

X 

X 

initialize a key for use in encryption 

setpwent)) 

X 

X 

X 

reposition to the start of the password file 

setutent)) 


X 


reposition to the start of an accounting file 

sleep)) 

X 

X 

X 

suspend process execution for an interval of time 

srand)) 

X 

X 

X 

reset random number generator at a random starting 





point 

swab)) 

X 

X 

X 

exchange adjacent bytes 

tdelete)) 


X 


remove a binary tree node 

timezone)) 

X 


X 

get the name of the timezone 
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toascii() 


X 


convert integer values to ASCII 

tolowerf) 

X 

X 

X 

translate characters to lower case (function in Sys V) 

toupper() 

X 

X 

X 

translate characters to upper case (function in Sys V) 

_tolower() 


X 


macro version of the tolower function 

_toupper() 


X 


macro version of the toupper function 

tsearchf) 


X 


create and search a binary tree 

ttyname() 

X 

X 

X 

obtain the file name of a terminal in string format 

ttyslot() 

X 

X 

X 

locate the accounting file entry for a terminal user 

twalk() 


X 


traverse (walk) through nodes of a binary tree 

tzset() 


X 


set time zone variables using an environment variable 

utmpname 

) 

X 


specify the accounting file to be examined 

String Functions 




index)) 

X 


X 

search for occurrence of character 

rindex)) 

X 


X 

search backwards for occurrence of character 

strcat)) 

X 

X 

X 

concatenate two full strings 

strchr)) 


X 


search for occurrence of character, like indexf) 

strcmp)) 

X 

X 

X 

lexical comparison of two full strings 

strcpyl) 

X 

X 

X 

copy a string into a second string 

strlen)) 

X 

X 

X 

obtain the length of a string 

strncat)) 

X 

X 

X 

append up to "n" characters to a string 

strncmp)) 

X 

X 

X 

lexical comparison of no more than "n" characters 

strncpy)) 

X 

X 

X 

copy "n" characters of a string 

strnspn)) 


X 


obtain length of initial string consisting of characters 





excluded from a second string 

strpbrk)) 


X 


search for a member of a set of characters 

strrchr)) 


X 


search backwards for occurrence of character, like 





rindex)) 

strspn)) 


X 


obtain length of initial string consisting of characters 





from a second string 

strtok)) 


X 


search a string one token at a time 

Standard I/O Library 




clearerr)) 

X 

X 

X 

reset error, end of file indicators 

cterm id() 


X 


obtain the filename for a terminal 

cuserid)) 


X 


obtain the login name of user as a string 

fclose)) 

X 

X 

X 

close a data stream 

fdopen)) 

X 

X 

X 

connect a data stream to an open file 

feoff) 

X 

X 

X 

test for an end-of-file condition 

ferror)) 

X 

X 

X 

test for error conditions 

fflush)) 

X 

X 

X 

flush a data stream without closing it 

fgetcl) 

X 

X 

X 

read a character from an input data stream 

fgetsf) 

X 

X 

X 

read a string, but no more than "n" characters 

fileno)) 

X 

X 

X 

obtain the file descriptor for a data stream 

fopen)) 

X 

X 

X 

open a data stream 

fprintf)) 

X 

X 

X 

place output in a named output stream 

fputcl) 

X 

X 

X 

write a character on a data stream 

fputs() 

X 

X 

X 

write a string onto an output stream 

fread)) 

X 

X 

X 

read buffered input from a data stream 

freopen)) 

X 

X 

X 

redirect output of an open data stream 

fscanf)) 

X 

X 

X 

scan input data from a named input stream 

fseek)) 

X 

X 

X 

reposition random read/write pointer 
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Routine 

V7 

Availability of Library Routines 

Sys V 4.2 Comment 

Standard I/O 

1continued) 

ftell() 

Library 

X 

X 

X 

determine current position in a data stream 

fwrite() 

X 

X 

X 

write buffered output to a data stream 

getcf) 

X 

X 

X 

read a character (macro version of fgetc) 

getchar() 

X 

X 

X 

read a character from the standard input (macro) 

gets,) 

X 

X 

X 

read a string up to a newline 

getw() 

X 

X 

X 

read a word from an input stream 

pclose() 

X 

X 

X 

close an interprocess data stream 

popenl) 

X 

X 

X 

open an interprocess data stream 

printf() 

X 

X 

X 

place output in the standard output 

putc() 

X 

X 

X 

write a character (macro version of fputc) 

putchar() 

X 

X 

X 

write a character to the standard output (macro) 

puts,) 

X 

X 

X 

write a string and append a newline 

putw() 

X 

X 

X 

write a word on an output stream 

rewind() 

X 

X 

X 

reposition to the beginning of a data stream 

scanf() 

X 

X 

X 

scan input data from the standard input 

setbuff) 

X 

X 

X 

assign a buffer to a data stream 

sprintf)) 

X 

X 

X 

place output in a character stream 

sscanf() 

X 

X 

X 

scan input data from a character string 

ssignalf) 

system!) 

X 

X 

X 

X 

specify action to perform upon receipt of a signal 
issue a shell command 

tempnamf) 

tmpfile() 

tmpnam() 

ungetcf) 

X 

X 

X 

X 

X 

X 

obtain filename for temporary file in any directory 

create a temporary file 

obtain filename for temporary file in /tmp 

put a character back into the input data stream 

Math Library 

hypot|) 

X 

X 

X 

Euclidean distance 

acos() 

X 

X 

X 

arccosine function 

asin() 

X 

X 

X 

arcsine function 

ceil,) • 

X 

X 

X 

ceiling function 

loglO|) 

X 

X 

X 

common logarithm 

cos|) 

X 

X 

X 

cosine function 

exp|) 

X 

X 

X 

exponential 

floor() 

X 

X 

X 

floor function 

cosh() 

X 

X 

X 

hyperbolic cosine function 

sinh() 

X 

X 

X 

hyperbolic sine function 

tanh() 

X 

X 

X 

hyperbolic tangent function 

fabs() 

X 

X 

X 

floating point absolute value 

abs|) 

X 

X 

X 

integer absolute value 

matherr() 

log|) 

X 

X 

X 

X 

math library error handling function 
natural logarithm function 

pow() 

X 

X 

X 

raise a value to a given power 

sin() 

X 

X 

X 

sine function 

sqrt|| 

X 

X 

X 

square root 

tan() 

X 

X 

X 

tangent function 

gammaf) 


X 

X 

log gamma function 

fmod() 

erfc|) 

erf|) 

atan() 

X 

X 

X 

X 

X 

X 

remainder function 

complementary error function : I - erf(x) 
error function : erf(x) 
arctangent function 

atan2() 

X 

X 

X 

arctangent function 

j[01 n]() 

X 

X 

X 

Bessel functions of the first kind 

y(01n]() 

X 

X 

X 

Bessel functions of the second kind 
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Miscellaneous 




• 

Routine 

5 





arc() 


x 

X 

X 

draw arc given the center and end points 

assert() 


X 

X 

X 

debugging macro for embedding diagnostic code 

circled 


X 

X 

X 

draw circle given center and radius 

closepl)) 


X 

X 

X 

close a plotting device, writing buffered output 

cont() 


X 

X 

X 

draw line between current position and second point 

curses 



X 

X 

cursor addressing and screen updating library 

dbm 


X 


X 

database management subroutines 

directory 




X 

directory operations 

erased 


X 

X 

X 

clear the plotting area 

label)) 


X 

X 

X 

supply labels for plotting 

line() 


X 

X 

X 

connect two data points with a line 

linemod() 


X 

X 

X 

specify style for connecting lines 

logname() 


X 


obtain the login name of a user 

move)) 


X 

X 

X 

reposition the cursor 

mp 


X 


X 

multiple precision integer arithmetic library 

openpl)) 


X 

X 

X 

prepare plotting device to receive data 

point)) 


X 

X 

X 

plot a data point 

regcmpf) 



X 


compile a regular expression 

regex() 



X 


execute regular expression for a pattern match 

re_comp| 

) 



X 

compile a regular expression 

re—exec() 




X 

execute regular expression for a pattern match 

space)) 


X 

X 

X 

define the perimeter of a plotting space 

termlib 



X 

X 

terminal-independent operation library 

varargs 




X 

variable argument list 

Network Routines 





byteorderf) 



X 

convert values between host and network byte order 

gethostent)) 



X 

get network host entry 

getnetentf) 



X 

get network entry 

getprotoentf) 



X 

get protocol entry 

getservent)) 



X 

get service entry 

inet_addr() 



X 

Internet address manipulation 

rcmd() 




X 

return stream to remote command (superuser) 

rexec() 




X 

return stream to remote command 


Continued from page 68 
and 4.2BSD (almost identical ver¬ 
sions of pcc) have been improved 
since Version 7. Both compil¬ 
ers now support enumeration 
data types, non-unique structure 
member names, and the void 
data type (for functions not re¬ 
turning a value). Long program 
identifiers are supported in 4.2, 
but were not added to System V 
until release 2. Both System V 
and 4.2BSD offer profiled func¬ 
tion libraries as an aid for soft¬ 
ware debugging, which means 
that profiling is supported at the 
library function level rather than 
simply at the user program func¬ 
tion level. 


When should library routines 
either found only on System V or 
4.2BSD be used? And when 
should you restrict yourself to 
library routines found on every 
version of UNIX? If you already 
have application software on the 
market, you’ll probably be forced 
to support all versions of UNIX. 
But if you’re writing software 
now that will reach the market 
in a year or so, you’ll probably 
find System V compatibility al¬ 
most everywhere by then. If you 
need the networking capability of 
4.2BSD, then use the Berkeley 
system because it will probably 
find its way onto System V before 
long. 


Bill Freiboth is President of 
Pacific Micro Tech , an El Cerrito , 
CA , firm engaged in system integra¬ 
tion , publishing , and consulting. He 
formerly served as Vice President 
of R&D at Decimus Corporation , 
where he helped design vertical 
market applications for financial 
institutions and assess IBM equip¬ 
ment for leasing. 

Bill Tuthill was a leading UNIX 
and C consultant at UC Berkeley for 
four years prior to becoming a 
member of the technical staff at Sun 
Microsystems. He enjoys a solid 
reputation in the UNIX community 
earned as part of the Berkeley team 
that enhanced Version 7 (4.0, 4.1, 
and 4.2BSD). ■ 


UNIX REVIEW NOVEMBER 1985 73 






Smalltalk has been a big con¬ 
versation piece ever since its 
introduction over a decade ago. 
Despite this, many people still are 
very confused about what Small¬ 
talk is and what significance it 
has for the computing communi¬ 
ty. To help clarify, I recently 
visited with Dan Ingalls, one of 
the system’s original designers 
from the Xerox Palo Alto Re¬ 
search Center (Xerox PARC), 
who—like many of his compatri¬ 
ots—has since migrated to Apple 
Computer. After we talked for a 
while in his office at Apple, he 
switched on his Macintosh to give 
me a preview of what the com¬ 
pany’s new Smalltalk environ¬ 
ment will look like. 

He called up a few windows 
and menus and showed how the 
scroll bar allows one to move 
around in a document, but all the 
while I was getting fidgety waiting 
for the Smalltalk demo to start. 
After all, I already knew how to 
use a Mac. So when Ingalls start¬ 
ed to demonstrate how to use 
what I took to be MacWrite, I 
finally asked, “Dan, when are we 
going to get into Smalltalk?’’ He 
looked at me with a puzzled 
expression and replied, “This is 
Smalltalk.’’ 

As it turns out, many of the 
concepts the Macintosh uses 
come from Smalltalk. In 1979, 
Xerox enlisted the support of 
Apple, DEC, HP, and Tektronix to 


INDUSTRY 

.INSIDER. 


What is Smalltalk anyway? 

by Mark G. Sobell 



help it debug Smalltalk. One of 
Smalltalk’s primary goals was to 
be a portable environment, so 
Xerox decided that one of the best 
ways to debug portability was to 
let several vendors try to bring up 
the system on a variety of ma¬ 
chines. As part of this process, 
Xerox gave Apple certain rights to 
Smalltalk after Apple had suc¬ 
ceeded in exorcising the system to 
Xerox’s satisfaction. 

A while later Apple came out 
with the Macintosh (not to men¬ 
tion the Lisa) which, although not 
a Smalltalk machine, certainly 
emulated the Smalltalk environ¬ 
ment. A number of the user 
interface techniques originated at 
Xerox PARC (overlapping win¬ 
dows, mice, pop-up menus, scroll 
bars) have since appeared on a 
number of other systems, notably 
some of the graphics-oriented 


UNIX systems. 

SMALLTALK'S JARGON 

Smalltalk, the brainchild of 
Alan Kay, has its roots in Simula 
and message passing. According 
to Ingalls, “Alan often takes an 
extreme point of view—that’s 
what makes him a good visionary. 
He took the message-sending 
model of procedure invocation to 
its logical extreme in designing 
Smalltalk.’’ In so doing, he cre¬ 
ated a world of objects. Each 
object is an instance of a class ; 
the class describes the format 
and also the behavior of all its 
instances. When anything is 
done in Smalltalk, it happens 
because an object receives a 
message. The statement: 

days + 4 

thus actually reads as, “send the 
message 4 + 4’ to the object days’’. 
Exactly what is done with the 
message depends on how the 
receiver, in this case days, inter¬ 
prets the + . The code that days 
runs in response to the message 
“ +4’’ is called a method. Finally, 
classes are arranged in an inheri¬ 
tance hierarchy so that user- 
defined classes typically inherit 
many of their useful properties 
from pre-existing classes in the 
Smalltalk system. 

Although the individual con¬ 
cepts seem simple enough, the 
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whole picture is elusive. In the 
introduction to their book on 
Smalltalk, Goldberg and Robson 
(see the references at the end of 
this column) explain this phe¬ 
nomenon by saying, “Due to the 


uniformity with which the object- 
message orientation is carried out 
in the system, there are very few 
new programming concepts to 
learn in order to understand 
Smalltalk. These concepts are 


presented by defining the five 
words that make up the vocabu¬ 
lary of Smalltalk—object, mes¬ 
sage, class, instance, and meth¬ 
od. These five words are defined 
in terms of each other, so it is 
almost as though the reader must 
know everything before knowing 
anything.” 

During the demo I started to 
realize the advantage of Small¬ 
talk is that it is a complete 
environment one can structure in 
any way—and with any look— 
that one likes. It can respond in 
whatever manner you wish be¬ 
cause beneath the environment 
lies a very malleable, portable, 
object-oriented language. 

FUTURE SMALLTALK 

Until recently, people outside 
academia had three major prob¬ 
lems with Smalltalk. First on the 
list was cost and availability: the 
system would only run on a 
$30,000 Xerox machine that 
you couldn’t buy. Last year, Tek¬ 
tronix introduced Smalltalk on a 
$15,000 piece of hardware. This 
year, it has been brought up on 
the IBM PC/AT, and a pre-release 
version is available for the 512 
KB Macintosh. 

The second problem was that 
Smalltalk ran very slowly on most 
machines. With the advent of the 
68020 and other fast micro¬ 
processors, Smalltalk should run 
at an acceptable rate on less 
expensive, single-user machines. 

The third problem—yet to be 
solved—is that because Small¬ 
talk is a whole environment, it 
takes up a great deal of space. You 
can put only a limited subset of 
Smalltalk on a 512 KB Mac, and 
even then you have only enough 
room left over for a minor pro¬ 
gram. You really need a 1 MB Mac 
with a hard disk to bring up a 
useful version of the full system. 

WHAT IS APPLE UP TO NOW? 

A product named MacApp (for 
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It’s simple, C-CALC from DSD Corporation is 
more flexible, has more functions, and is easier 
to use than the best selling spreadsheet. We 
made it that way for a very simple reason, you’ll 
get more work done and make better decisions 
in less time. That’s what makes you successful 
whether you are planning for the future, fore¬ 
casting trends, or analyzing profits. 

The most popular spreadsheets require a great 
deal of time to get up and running. When we 
created C-CALC we kept in mind that time is 
your most important resource. Our On-Line 
Help facilities, prompts and menus allow even 
someone with minimal experience to see 
meaningful results in very little time. Our built- 
in training procedures let you pace your own 
learning with tutorial topics that range from 
basic to advanced. As you become more expe¬ 
rienced, C-CALC allows you to bypass 
prompts and menus to save even more time. 

So call DSD Corporation at (206) 822-2252. 
C-CALC is currently available for: UNIX, VMS, 
RSTS, RSX, IAS, P/OS, AOS, AOS/VS (Data 
General), IBM CSOS. 


C-CALC is a registered trademark of DSD Corporation UNIX is a registered 
trademark of Bell Labs. P/OS, RSTS and RSX are registered trademarks of 
Digital Equipment Corporation. AOS and AOS/VS are registered trademarks 
of Data General Corporation. 
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Macintosh Application) is already 
into beta test at Apple. MacApp is 
an extended, object-oriented Pas¬ 
cal language that Apple claims 
will help software developers cut 
the amount of time it takes to 
code an application. One reason 
for the claim is that MacApp 
comes complete with a user-inter¬ 
face library. You can use the 
library to code the user-interface 
portion of an application quickly, 
writing the nuts and bolts in 
Pascal. But MacApp, like Pascal, 
is a conventional, compiled lan¬ 
guage: you need to edit your 
source, compile it, and then link it 
before you can execute it. This 
tedious procedure is not good for 
prototyping applications. 

Because Smalltalk is a good 
prototyping language, Apple is 
currently converting it to the 
architecture of MacApp. With 
this compatibility, developers will 
have the option of prototyping 
an application in the friendly 
Smalltalk environment and then 
porting it to a more conventional 
system for increased efficiency 
and security. If it flies, the Mac- 
App/Smalltalk connection could 
be inviting to application develop¬ 
ers—a prospect that Apple finds 
very intriguing indeed. 

If you have an item appropri¬ 
ate for this column , you can 
contact Mr. Sobell at 333 Cobalt 
Way. Suite 106 , Sunnyvale. CA 
94086. 


Mark G. Sobell is the author of 
the bestselling book, A Practical 
Guide to the UNIX System (Benja¬ 
min/Cummings, 1984) and the new 
A Practical Guide to UNIX System V 
(Benjamin/Cummings, 1985). He 
has been working with UNIX for 
over five years and specializes in 
documentation consulting and troff 
typesetting. Mr. Sobell also writes, 
lectures, and offers classes in Ad¬ 
vanced Shell Programming and 
awk. ■ 


For more information about Smalltalk, try 
to find a copy of the August. 1981, issue of 
Byte, which is almost entirely devoted to the 
subject. There are also two books written by 
Smalltalk developers: Smalltalk-80: The 
Language and its Implementation by Gold¬ 
berg and Robson, and Smalltalk-80: The 


Interactive Programming Environment by 
Goldberg. Both are published by Addison- 
Wcsley. You can obtain more information on 
the unsupported pre-MacApp version of 
Smalltalk by writing to Eileen Crombie, 
Software Library. Apple Computer. Inc., 
20525 Mariani Drive, Cupertino. CA 95014. 



Finally, a complete XENIX 
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Disk Features 

• 30, 40, 55, 72, 118 Megabytes 
(iformatted) 

• Combine drives with each other or 
existing drive 

• 25 milliseconds average access time 

• Simplified installation 

• Necessary file modifications done 
automatically 

Tape Features 

• 60 Megabyte 1/4 inch cartridge 

• Standard XENIX commands (cpio, tar, 
dd, etc.) 

• Fully integrated driver software 


Subsystem Features 

• Entire subsystem fits inside the AT 

• External version with 6 expansion 
slots available (pictured) 

• One year factory warranty 


Emerald 

Systems Corporation 

Mainframe Storage for Micros 

4757 Morena Boulevard 
San Diego, CA 92117 
(619) 270-1994 
Telex 323458 EMERSYS 
EasyLmk 62853804 


Emerald & Mainframe Storage for Micros''* Emerald Systems Corp. 
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RULES 

OF THE GAME 


Monkey business 

by Glenn Groenewold 


Readers who have been wait¬ 
ing on the edge of their seats for 
further developments in the saga 
of Jack Megabyte need wait no 
longer. When we last reported on 
this drama in the October, 1984, 
column, Jack was being hassled 
by his former employer, Goli¬ 
ath Corporation, because—along 
with Helga Termcap, another ace 
systems designer—he had start¬ 
ed a business with the intention 
of developing and marketing 
a new operating system capable 
of outperforming Goliath’s. The 
latter was throwing up legal 
roadblocks against this enter¬ 
prise, claiming that Goliath—not 
Jack—was the owner of any new 
system he had dreamed up while 
in the company’s employ. 

When we took leave of Jack 
and Helga, we intimated that they 
most likely would have effective 
weapons of their own in the legal 
battle with Goliath. An important 
part of their arsenal for counter¬ 
attack could be found among the 
group of legal actions collectively 
known as business-related torts. 
Given the increasing frequency 
with which the game of employee 
musical chairs is played these 
days, both in American business 
generally and in the comput¬ 
ing industry in particular, these 
bases for legal actions (there are 
more than 20 altogether) are 
seeing more and more use, as are 
some of the more familiar legal 



varieties of claims for injuries. 


WHAT IS THIS THING 
CALLED "TORT"? 

Non-lawyers often find the 
term “tort” somewhat amusing. 
But it’s a venerable concept in 
law, where it distinguishes a civil 
impropriety from one that is 
criminal in nature. During the 
early history of our legal system, 
the two categories were pretty 
much distinct. In recent years, 
however, they’ve become blurred 
to the point where it’s not unusu¬ 
al for a single act to be the basis 
both for a civil lawsuit and a 
criminal prosecution. 

What’s more, we even have 
situations where the same indi¬ 
vidual may be regarded simulta¬ 
neously as an “innocent” injured 
party under one concept and as 
a malefactor under the other. 


Thanks to nationwide reportage, 
many people are aware of the 
notorious California case involv¬ 
ing a would-be burglar who in¬ 
jured himself falling through a 
skylight on the victim’s roof, and 
then successfully sued on ac¬ 
count of his injuries. 

Despite this modern-day mud¬ 
dying of the water, the basic 
notion of a tort remains what it 
has always been: a private 
wrong, as opposed to a public one. 
This is why it’s such a useful legal 
concept for individuals who’ve 
been injured by someone else’s 
actions. 

Some torts, such as slander 
and libel , are ancient. Others 
have developed relatively recent¬ 
ly, or have been expanded far 
beyond their historical scope. 
The concept of “infliction of emo¬ 
tional distress” is a prime exam¬ 
ple. In the current sense, this 
tort scarcely existed in common 
law, and was almost impossible 
to prove before its modern 
evolution. 

THAT UNCERTAIN FEELING 

Since business-related torts 
are a matter of state law, not all of 
them exist in every state. And 
when the same tort is found in 
various states, it may be known 
by various names. Some business 
torts clearly have no application 
to disputes involving a former 
employer, an erstwhile employee, 
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FUSION Is the only connection. 


In an industry fragmented by diversity, FUSION 
makes connections. 

FUSION is the LAN software that links different 
operating systems, diverse LAN hardware, and di¬ 
verse protocols, to give you high speed communi¬ 
cation across completely unrelated systems. 

FUSION frees you to buy the best computer for 
the job—without worrying about compatibility. 
Your VAX mainframe can now communicate with 
your IBM-PC. You can even add M68000 work 
stations or a communications server. FUSION 
links them till—and more. Regardless of operating 
system, protocol, or network hardware. 



■ With FUSION, any user on any system can 
perform file transfer, remote login, and 
remote execution. 

■ FUSION offers a choice of two standard 
protocols—XNS or TCP/IP. Some cus¬ 
tomers have even developed private 
protocols. 

■ And you can create your own application 
programs, using FUSION utilities. 

■ FUSION accommodates all major LAN 
boards, too. So network interface is no 
obstacle. 


When you add FUSION, you never lose your 
hardware investment. In fact, you get more out of 
it than ever. 

Ask for FUSION. It's the connection you’ve 
been looking for. 
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3COM 





A sample network using a few of the many 
configurations made possible with FUSION. 

For further information please contact: 
Network Research Corporation 
2380 North Rose Avenue 
Oxnard, California 93030 
(805) 485-2700 
(800) 541-9508 

FUSION is a licensed trademark of Network Research Corporation. 
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U RULES OF THE GAME 


or the latter’s new employer or 
business enterprise. But in a 
given situation, the relevance of 
some of these other disputes may 
be the subject of contention. 

Moreover, the legal require¬ 
ments necessary to prove any of 
these actions are highly techni¬ 
cal, and vary from state to state. 
As a result, it’s not possible here 
to do more than to suggest reme¬ 
dies that might be available to 
participants in controversies re¬ 
sulting from the ongoing business 
activities of a former employee. 

FROM THE EMPLOYEE'S 
PERSPECTIVE 

Two alternative possibilities 
exist when a departing employee 
intends to continue a remunera¬ 
tive activity in potential competi¬ 
tion with a former employer. Each 
presents a different legal scenar¬ 
io. On the one hand, the employee 
may expect to take a job with 
another concern in the same 
field. Or, as with Jack Megabyte, 
he or she may attempt to launch a 
competing enterprise. We’ll begin 
by considering the first of these 
situations. 

There are several ways an 
employer might find itself on the 
receiving end of a lawsuit brought 
by a former employee if it seeks to 
prevent employment by a com¬ 
petitor. For instance, if it re¬ 
sponds to an inquiry on the part 
of the prospective employer with 
something like, ’’Well, hire her if 
you want to, but you ought to 
know about her $150 a day 
habit”, or perhaps, ’’We’re happy 
he left before he got a third 
receptionist pregnant”, it had 
better be able to prove these 
things, lest it find itself stuck 
with damages for the old-fash¬ 
ioned tort of slander (or def¬ 
amation , as it’s often called 
nowadays). Even if the former 
employer can establish that any 
personal information of this sort 


is true, it may nevertheless find 
itself sued on the basis of inva¬ 
sion of privacy. 

Assuming the employer does 
not resort to such canards, but 
still dissuades a prospective new 
employer from hiring its ex-em¬ 
ployee, it might nevertheless ex¬ 
pose itself to a claim of inter¬ 
ference with prospective eco¬ 
nomic advantage. For example, 
suppose it threatens to bring a 


We have situations 
where the same 
individual may be 
regarded 

simultaneously as an 
"innocent" injured 
party under one 
concept and as a 
malefactor under the 
other. 


lawsuit against the prospective 
employer if it hires the for¬ 
mer employee, or to terminate 
a licensing or distribution 
agreement. 

Finally, if all else fails, in 
liberal jurisdictions like Califor¬ 
nia there’s the rapidly expanding 
tort of infliction of emotional 
d istress to give redress to a former 
employee who has been blocked 
vindictively from obtaining new 
employment. 

Where the employee proposes 
to follow the alternate route of 
launching his or her own busi¬ 
ness and the former employer 


attempts to thwart this, some of 
the legal actions just mentioned 
may be available. However, there 
are others as well. 

The basic business tort apply¬ 
ing to this type of situation is 
interference with the right to 
pursue a lawful business , which 
is pretty much what its name 
suggests. In addition, there are 
less obvious measures that may 
present themselves in certain 
cases. 

If the former employer has 
required the employee to disclose 
all of his or her creations during 
the employment, and the facts 
indicate that the material in 
question actually was created 
outside the scope of employ¬ 
ment—making it the employee’s 
property—a claim of misappro¬ 
priation of trade secrets or 
copyright infringement may be 
in order. (The latter, since 1978, 
has been exclusively within the 
jurisdiction of the federal courts. 
It therefore no longer constitutes 
a state business tort.) 

If none of these actions ap¬ 
pears to fit, the situation may 
permit an action on the basis of 
unfair competition. Originally, 
in common law, this tort was 
rather narrow in scope, essential¬ 
ly applying only to situations in 
which the buying public had 
been misled by some action on 
the part of a business competitor. 
In recent years, it has expanded to 
become rather a catch-all, so that 
it now can encompass such 
things as unfair tactics on the 
part of a former employer de¬ 
signed to prevent competition 
from its ex-employee. 

FROM THE FORMER 
EMPLOYER'S PERSPECTIVE 

The employer, however, is not 
exactly without legal weapons for 
use in lawsuits against its es¬ 
tranged employee, and, in some 
cases, in actions against a new 
employer who has alienated the 
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y RULES OF THE GAME 


employee's affections. 

The latter can itself be sued for 
misappropriation of trade se¬ 
crets if it can be shown that one of 
the reasons it hired the employee 
was to obtain access to the trade 
secrets that he or she had learned 
in the former employment. The 
new employer could also be the 
subject of a claim of unfair com¬ 
petition for having lured a key 
employee away from its competi¬ 
tor, or it could be sued for induc¬ 
ing a breach of contract —which 
in this case would be the employ¬ 
ee's contract of employment with 
the former employer. In some 
states, the new employer also 
might be liable for interference 
with an employment relation¬ 
ship, though this tort ordinarily 
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Franz LISP from Franz 
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has been applied only when a 
physical injury has occurred to 
an employee. Thus, from our 
standpoint, this tort largely would 
appear to be preempted by the 
tort of unfair competition. 

Turning its attention to its 
former employee, the erstwhile 
employer may have legal actions 
available based on misappro¬ 
priation of trade secrets , copy¬ 
right infringement , or unfair 
competition , all of which have 
been discussed here. But it may 
also have a claim based upon the 
employee’s breach of contract. 
This is where the contract of 
employment between the employ¬ 
er and employee (which we con¬ 
sidered last September) becomes 
highly important. 


TVee Shell 
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If, for example, the employee 
had agreed that he or she would 
not take employment with a com¬ 
petitor for a specified time after 
leaving the first employer, or 
would not start a business in 
competition with the employer, 
this provision might be enforce¬ 
able, depending on all of the 
circumstances. But because rea¬ 
sonable restrictions of this type 
may be valid in whole or in part, 
employees in key positions should 
take the precaution of obtaining 
competent advice at the time the 
terms of their employment are 
negotiated. 

AND NOW, BACK TO OUR 
STORY 

So what is to happen with Jack 
Megabyte in his legal battle with 
Goliath? 

I hope the contents of this 
article are sufficient to illustrate 
why 1 can’t possibly answer that 
question with any degree of cer¬ 
tainty. In most places, the odds 
are that the various lawsuits will 
take what seems like an eternity 
to go to trial. When they finally 
are debated in court, the results 
will depend on the multiplicity of 
facts that are developed and, of 
course, the laws of that particular 
state. 

I’d like to think that during the 
long wait, Jack will manage to 
strike it rich in the Publishers’ 
Clearinghouse sweepstakes and 
find time to luxuriate on Majorca, 
while Helga turns her talents to 
successfully franchising a chain 
of t'ai chi exercise studios, to her 
immense profit. We all like happy 
endings, don’t we? 

Glenn Groenewold is a California 
attorney who devotes his time to 
computer law. He has served as an 
administrative law judge , has been 
active in trial and appellate work , 
and has argued cases before the 
state Supreme Court. ■ 
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FIT 

TO PRINT 


It's in the stars 

by August Mohr 


A premise of the Whole Earth 
Catalog holds that the best intro¬ 
duction to a book is the book 
itself. I wholeheartedly agree, so 
in launching this new book re¬ 
view column I will attempt to let 
authors speak for themselves in a 
way that, I hope, will let you get 
an accurate idea of what the book 
is about. 

Three “guides” to UNIX have 
crossed my desk in the past 
month or so, and for different 
reasons they all deserve com¬ 
ment. They are: The UNIX Envi¬ 
ronment , by A.N. Walker; A Prac¬ 
tical Guide to UNIX System V, by Mark G. Sobell; 
and XENIX by Example , by The Staff of M & M 
Technologies Corporation. 

The UNIX Environment 



Andrew N. Walker 
151 +xi pp. ISBN 0-471-90564-X 
John Wiley & Sons, 1984 
605 3rd Ave. 

New York, NY 10158 
$15.95 (paper) 

Walker has produced a delightful book. As soon 
as I opened it, he already had captured me with 
anecdotes. Walker clearly enjoys his subject, and his 
pleasure is infectious. 1 read passages to my wife, 
who knows little about UNIX, and got many honest 
chuckles from her. Walker’s lighthearted style is 
completely appropriate since the book is intended to 
communicate what using UNIX is like, rather than 


how it should be used. 

It is clear that Walker is writing 
to the computer professional who 
is not familiar with UNIX but 
wants to know more about it 
without actually having to use a 
system. In his own words: 

I hope that by the end of 
this book , ... if you do not 
already use Unix , you will 
be able to persuade your 
company , or your institu¬ 
tion , or your rich uncle , or 
whatever , to give you a Unix 
installation to play with. 
Unless you have an incredibly boring view of 
the nature of computing , your life will never 
be the same again. 

My own introduction to UNIX came by way of a 
1981 article in Computer magazine authored by 
Kernighan and Mashey called “The Unix Program¬ 
ming Environment”. This book is very reminiscent 
of that article. 

Walker also goes beyond introducing readers to 
the style of UNIX in his discussion of the system’s 
internals. Because he is writing to computer- 
oriented people, he explains the concept of fork and 
exec before he even gets to the shell. A discussion of 
the kernel’s view of the file system comes even 
earlier. 

How do we make available a particular 
block of the disc? Well , we first of all scan the 
buffer pool to see if the block is already 
available; if so, we can return immediately. If 
not , we have to find an empty buffer , issue a 
request to the hardware , and wait for the 
information to arrive. How do we find an 
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U FIT TO PRINT 


The best Introduction to a book is 
the book itself. 


empty buffer? Well, with luck there is one not 
in use at all. Failing that, we latch on to a 
buffer that has not changed from its equiv¬ 
alent on the disc; this can be re-used straight 
away. Failing that, wefind a buffer that is un¬ 
likely to be wanted soon, issue a request to 
the hardware to copy it back to the disc, and 
then we can grab it for our own purposes. 
Requests to the hardware are themselves 
buffered. and possibly dealt with out of order 
to improve efficiency. 

Naturally, real life is much more complicat¬ 
ed than its simplified description here. Ta¬ 
bles get full, buffers are soon all in use, and 
stringent precautions must be taken against 
deadlocks, races, errors, and breaches of 


IBM XENIX 
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120ns RAM, fully populated. Why pay more? 

FIND OUT about the IBM Unix® Solution with 
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quantity one price including all software. Why 
pay three times more for a slower machine? 

Bell Technologies Call today for 

415-794-5908 / PO Box 8323 quantity 
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security; but such fine detail can safely be left 
to the reader's imagination. 

In keeping with the notion of a computer-literate 
audience. Walker discusses interprocess communi¬ 
cation, make, and the C language before getting into 
the vi editor and nroff. His discussion of C is 
excellent, both as an introduction to the flavor of the 
language and for its comparisons with other 
languages. His sample programs all have good style. 
The largest, 22 lines, is a working program written 
to reformat a tape file intended for another system. 
His top-down, line-by-line explanation of the pro¬ 
gram’s use of pointers should help make C compre¬ 
hensible even to people who have only BASIC 
experience. 

The use of {...} to bracket compound 
statements, rather than the more usual begin 
. •. end. and the elision of then are typical de¬ 
tails that contribute to the rather opaque 
appearance of C. Many of my students use the 
macro pre-processor facility to define: 

^define IF iff 
^define THEN ){ 

^define ELSE : |else{ 

^define FI ;} 

(for example), to replace strings of brackets 
by more readable keywords. After this they 
can pretend they are writing Algol 68: 

IF i ) j THEN x = y ELSE printf ("error!") FI 

I am disappointed that the book is limited to 
Version 7 UNIX, and that it often makes compari¬ 
sons with Version 6. This leaves readers to 
determine for themselves whether this or that 
problem or feature still exists in System III or 
System V. But since Walker’s book is not intended 
as a working manual, this is a minor problem. 

The book is well edited, as one would expect a 
John Wiley & Sons product to be. I did not find any 
obvious errors in the examples, and all of the quote 
marks were of the proper kind. The only typo I could 
find was an instance where the name of the root di¬ 
rectory was to be displayed on a line by itself, and 
only a blank line was produced instead. The 
author’s britishisms only occasionally bothered me: 
“disc” for “disk” I didn’t mind, but I stumbled over 
“transput” for “input/output’’. 

Command lines are universally separated from 
the text in a display format and set in a clean 
Helvetica type. The braces, brackets, stars, and 
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%J FIT TO PRINT 


Walker clearly enjoys his subject, 
and his pleasure is infectious. 


pipes are all clear. My only complaint about the 
layout is that there are no chapter references at the 
tops of the pages to help readers find their way 
around. That is acceptable in a book intended for 
regular reading, but headers should be mandatory 
in a reference work. Since the author clearly intends 
this as an informal introduction, this omission is 
forgivable here, but I like to browse and would have 
preferred landmarks. 


moving back from the middle of the current word to 
the beginning of the previous word. That is 
inaccurate. A better phrasing would have indicated 
that the cursor would move “to the previous first let¬ 
ter of a word.” The cursor should then be shown 
moving to the beginning of the current word. 

I hope such nitpicking does not give a false 
impression. This is a well-done book. 


Xenix by Example 



The Staff of M & M Technologies Corporation 
M & M Technologies Corporation, 1984 
PO Box 237 Herndon, PA 17830 
$39.95 (paper) 


A Practical Guide to UNIX System V 



Mark G. Sobell 

577 + xii pp. ISBN 0-8053-8915-6 

The Benjamin/Cummings Publishing Company, 

Inc., 1985 

2727 Sand Hill Road 
Menlo Park, CA 94025 
$20.95 [paper) 

Mark Sobell has updated his excellent book on 
Version 7 UNIX to include relevant aspects of 
System V. This book is intended to be both an in- 
depth tutorial and a reference guide. It succeeds well 
on both counts. 

One of the best aspects of the book is its use of ex¬ 
amples to illustrate the actions of different com¬ 
mands, options, and syntaxes. By giving readers the 
text of simple files and showing the various possible 
results, Sobell teaches a simple technique for 
establishing the behavior of a command without 
recourse to a manual. This may not seem like much, 
but for a beginner to learn the “try it and find out” 
approach can be a major threshold. Sobell makes it 
safe, easy, and alluring. 

His section on vi is one of the best available. 
Visual explanations for essentially two-dimensional 
commands make good sense, especially when 
they're well done—as they are in this book. 

However, despite the fact that Sobell’s new book 
is a revision, occasional errors have seeped through. 
For instance, he writes, “The b key moves the 
cursor backward to first letter of the previous 
word.” The accompanying picture shows the cursor 


This is a disappointing book. It is marred by poor 
editing and inaccurate examples. These problems 
are compounded by the fact that the book is also 
ugly. The index and table of contents were produced 
on a line printer, as were the diagrams—even the 
pictures of directory tree structures. The pages are 
numbered by chapter, making it difficult to locate 
oneself in the book. 

The book’s most redeeming feature is a nice 
section at the end telling of a week in the life of a sys¬ 
tem administrator. This piece actually serves as a 
useful description of the job. 

Because of the book’s orientation towards Xenix 


Xenix by Example is marred by poor 
editing and inaccurate examples. 


on Tandy systems, I suspect it is intended to be 
distributed as part of a package. In that form it may 
have some usefulness, but I would not recommend 
buying it separately for its own merits. It is not a bad 
book, but it could easily have been better. 

It's in the stars: 0 = kitty litter: 1 = take it if it’s free: 2 = worth the 
cover price: 3 = well worth reading: 4 = get the leather-bound edition. 


August Mohr is the new book review editor for UNIX 
REVIEW. With a background in both computer science 
and publishing, Mr. Mohr has combined these interests 
while working with the international UNIX users' 
organization /usr/group. He was the founding editor of 
the newsletter/magazine CommUNIXations, and also 
served as the compiler and producer of the group's UNIX 
Products Catalog. ■ 
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Z8000, 8086, NSC16032 


SSI TOOLKIT 


yy. 
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cross development tools for 
UNIX and VMS .™ Package 
includes macro cross 
assembler compatible with 
Intel ASM-8618718811861188, 
linker, locator and librarian. 


and 8080/Z80 m Cross 
assemblers provided for 
MC6800™ 16805™ /68097 
NSC16032 and Signetics 
2650 ™ Package contains 
complete sources. 


Z 


' y\ / 


PRICE: 

SVS Languages 

FORTRAN 77, 

Pascal, and C 
BASIC-PLUS 

u4th 

IBM-PCATr 
Intel 286/31O m 
MC68000 
VAX 

SSI Toolkit 

VAX (UNIX and VMS) 
MC68000 
Lattice C Cross Compiler 
VAX (UNIX and VMS) 5000 
MC68000 3000 

Amsterdam Compiler Kit 
Commercial users 9950 

Educational Institutions 995 

For our free catalogue and 
more information on these 
and other UNIX software 
products, call or write: 
UniPress Software, Inc., 

2025 Lincoln Hwy., 

Edison, NJ 08817. 

Telephone: (201) 985-8000. 
Order Desk: (800) 222-0550 
(Outside NJ). 

Telex: 709418. 

European Distributor: 
Modulator SA, Switzerland. 
Telephone: 413159 22 22, 
Telex: 911859 

OEM terms available. 
Mastercard and Visa accepted. 
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Setting the sights 

by Stan Kelly-Bootle 


I have been asked to keep you 
updated on my exciting chase 
after Ty Cobb’s lifetime hit total. 
My attempt will obviously chal¬ 
lenge Pete Rose’s record also, but 
that is entirely coincidental. Re¬ 
lax, Peter my dear boy, it’s Tyrant 
R. Cobb I’m after. 

For some time I’ve considered 
tackling Cobb’s achievements in 
non-Wrigley-type fields, off-the- 
plate as it were. Take Ty Cobb’s 
record in, say, MC68000 assem¬ 
bly language programming. You 
needn’t look it up; Cobb’s coding 
was unbelievably ineffective at all 
levels, pure Bugsville—0 for 
FFFF, man. There’s no fun in 
beating such an abysmal per¬ 
formance. 

No, the improbable dream 
should be made of sterner stuff, 
as Hamlet once remarked to Bru¬ 
tus. Why drive up Mount Tamal- 
pais when there are the Eigers to 
be scaled? Why grovel in RPG 
when the perfect payroll cries out 
for Lisp? You can test the eerie 
intelligence of Lisp by typing: 

(GET STAN RAISE) 

which sadly but correctly re¬ 
turns: NIL. 

So here is the challenge I have 
taken on amidst a sea of doubting 
sniggers: 

Ty Cobb's record: 

Total Hits_4191 



Stan “Mr. November’’ Kelly-Bootle: 


Last Game_D-5 

Total Hits_0 

Hits still needed to tie Ty_4191 

Hits still needed to pass Ty_4192 

Hits still needed 

to completely humiliate Ty _8192 


You will be relieved to learn that I 
plan to retire at this very point, 
just as my 11 -bit register over¬ 
flows! 

Be sure to follow my progress, 
reported exclusively here in UNIX 
REVIEW every month; you will 
definitely not find it in the so- 
called Sporting Press. (I leave you 
to draw your own conclusions; 
just remember that Pete Rose’s 
first at-bat also attracted very 
little attention from these same 
smart-alec jockscribes.) 

I am not the only Quixote on 
the block! Indeed, I am much 


encouraged by letters from Doro¬ 
thy D’Attoma, the lively PR per¬ 
son for Multi Solutions Inc., cre¬ 
ators of the S1 operating system. I 
have a theory that SI stands for 
Sisyphian # 1, indicating that 
Dorothy has one hell of an uphill 
assignment, namely dislodging 
UNIX from the top of the heap. 

I recall selling Univac’s Exec8 
against IBM’s OS360 in those 
carefree days of core. (By the way, 
whatever happened to plated- 
wire memory? Sure, it was three 
bucks-a-byte, but very pretty.) If 
we were asked if Exec8 had a 
certain feature or property, we 
would ponder to ourselves if such 
a feature or property seems sensi¬ 
ble and desirable. If so, our an¬ 
swer would be an enthusiastic 
affirmative: “Yes, sir. What’s 
more, it’s transparent to the 
user.’’ We would then rush off a 
cable to Sperry HQ in Bluebell, PA 
pleading for enhancements. 

Another historical curiosity 
springs to mind, although it pre¬ 
dates my own personal involve¬ 
ment. During the 1840s, the 
British steam locomotive rail sys¬ 
tem had evolved haphazardly 
with private companies building 
networks with different track 
widths. Each, of course, had con¬ 
vincing arguments why a 5-foot 
6-3/4 inch gauge was either a 
God-given boon or a pitiful, dia¬ 
bolical trap. Certainly those with 
trains and rolling-stock running 
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on wheels 5-foot 6-3/4 inches 
apart had difficulty admitting the 
sanity of anyone who sang the 
praises of a 7-foot 1-inch wide 
track. 

Nevertheless, the greatest en¬ 
gineer of the day, Isambard King¬ 
dom Brunei (1806-59), proved 
beyond doubt that the wider track 
offered a safer, more comfortable 
ride. Further, he went ahead and 
built the Great Western Railway 
on this basis. For a few years, 
trains were actually designed 
with adjustable wheels, allowing 
them to make the journey from, 
say, Norwich to Bristol with two or 
three stops for wheel adjustment 
(preferable to the alternative “All 
Change!” for goods and passen¬ 
gers). Alas, poor Brunei was just a 
little late; the narrow gauge, 


devised before all the design 
implications were known, be¬ 
came the prevalent, unshakeable 
standard. 

This raises the obvious ques¬ 
tion (if you like simplistic analo¬ 
gies): is UNIX running on the right 


Is UNIX running on the 
right lines for the 
wrong reasons? 


lines for the wrong reasons? Or 
vice versa? Who’s on first? Not 
me. I’m still looking for the first of 


those damned elusive 4191 hits. 

Newsflash : T. Boone Pick has 
taken over AT&T and the Univer¬ 
sity of California at Berkeley. His 
operating system has been de¬ 
clared the ad hocissimus stan¬ 
dard. All Change! 

Damn, now where did I put my 
old BASIC manuals? 


Liverpool-born Stan Kelly-Bootle 
has been computing, on and off, at 
most levels since the pioneering 
EDS AC I days in the early 1950s at 
Cambridge University. After graduat¬ 
ing from there in Pure Mathematics, 
he gained the world's first post¬ 
graduate diploma in Computer Sci¬ 
ence. He has authored The Devil's DP 
Dictionary and co-authored Lem Yer- 
self Scouse and The MC68000 Soft¬ 
ware Primer. ■ 



Q-Calc is an extraordinary _ r _ 

for UNIX including extensive math 
and logic facilities, comprehensive 



Price: 

// 

VAX, Pyramid, AT&T 

(with graphics) 3500 

programs via pipes, filters and sub- MC68000™ 750_ 

processes. Data can be processed 
interactively by UNIX. Source Code Avail 

■ Q-Calc profile mechanism allows 

the user to store default information, For our Free Catalogue and more 
as well as support for terminal-specific information on these and other UNIX 
profiles. Uses termcap. software products, call or write: 

m Graphics for bar and pie charts. ‘ , ~' n — r '-*-— 

Several device drivers supported, 
m New Features of Version 3.2 


. new string operator, 
bind-to-key, and more. 

. dr the VAX”, Sun”, 

Masscomp”, AT&T 3B & 7300 Series, 
Pyramid”, Plexus”, Gould”, Cadmus”, 
\ted Solutions”, Cyb”, IRIS”, 
fan”, and many more. 



Trademarks ot: UNIX. AT&T Bell Laboratories; VAX. Digital Equipment 
Corp; Sun. Sun Microsystems; Masscomp. Masscomp; CYB. CYB 
Systems. Plexus, Plexus Computer; Gould. Gould, Pyramid, Pyramid. 
Integrated Solutions. Integrated Solutions; IRIS, Silicon Graphics, 
Cadmus. Cadmus Computer; Caltan. Callan Data Systems; MC68000. 
Motorola Corp 


Circle No. 281 on Inquiry Card 


/ / / 

IniPress Software 


y&t/r Leading Source for UNIX^Software 














Note: only the meanings most 
pertinent to scientific and real¬ 
time programming have been 
included in this listing. 

adaptive control—a regulation 
that alters the mode, speed, or 
type of system response accord¬ 
ing to changing circumstances or 
results. The use of adaptive con¬ 
trols is desirable in many kinds of 
real-time control systems, par¬ 
ticularly robotics. 

AP—an abbreviation for “ array 
processor" (see below) or “ at¬ 
tached processor" (also below). 

array processor—a special com¬ 
puter that acts as an assistant 
to another computer system by 
performing mathematical opera¬ 
tions on arrays of numbers. Ar¬ 
ray processors are widely used in 
some scientific applications be¬ 
cause they are much more ef¬ 
ficient at performing repetitive 
calculations than are general- 
purpose computers. UNIX offers 
no native support for array pro¬ 
cessors, but these machines have 
been integrated successfully into 
many UNIX systems. 

attached processor—any exter¬ 
nal but tightly-linked processor 
designed to speed the processing 
of specialized types of data. Ex¬ 
amples include array processors , 
communications processors, vid¬ 
eo processors, database engines, 


THE UNIX 
GLOSSARY 


Real-time vernacular 

by Steve Rosenthal 



and the like. Although UNIX does 
not include any explicit support 
for attached processors, the sys¬ 
tem’s general support for multi¬ 
tasking often eases the job of 
including such units. 

backend processor—a special¬ 
ized processing unit added to a 
computer system to speed the 
handling of certain types of data. 
It is called a “backend” unit 
because the ordinary user doesn’t 
see or interact with it; all instruc¬ 
tions pass through the main com¬ 
puter system. Array processors 
and database machines are the 
backend processors most com¬ 
monly encountered in the UNIX 
community. 

bang-bang controller—a con¬ 
troller with only one level of 
response, which is used when a 
monitored condition exceeds set 


limits. An example would be a 
furnace that turns on fully only 
when the temperature drops be¬ 
low 60 degrees and that turns off 
completely only whenever the 
mercury rises over 72. Bang-bang 
controllers are simpler to design 
and build than proportional con¬ 
trollers—which can order select¬ 
ed levels of response—but they 
often are less efficient. 

bounded interrupt latency—a 

quality possessed by systems that 
respond to interrupts within a 
specified maximum amount of 
time. Bounded interrupt support 
is necessary for many types of 
real-time process control. UNIX, 
however, normally cannot guar¬ 
antee such a limit, so most sys¬ 
tems responsible for process con¬ 
trol rely on modified UNIX kernels 
or resort to specially engineered 
precautions. See also determin¬ 
istic interrupt latency. 

computational element—one of 

the smaller processors in a multi¬ 
processor system. Computational 
elements are especially common 
in systems using large numbers 
of processors. Also called a “pro¬ 
cessing element”. 

contiguous disk storage—the 

assignment of logically-sequen- 
tial disk sectors to physically 
adjacent areas in preference to 
using an interleave factor to place 
them in intervening areas. Con- 
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tiguous disk arrangements make 
for faster data storage, which is 
often necessary for real-time sys¬ 
tems. However, they also require 
the use of a high-performance 
disk controller, and they may 
require that the system process 
data fast or defer processing alto¬ 
gether because of the limited time 
available between the reads or 
writes of successive sectors. 

critical resource —in multitask¬ 
ing computer systems, “critical 
resource” refers to a device, area 
of memory, or section of code that 
cannot be shared with other 
tasks. For example, two different 
tasks cannot be allowed to write 
to the same area of the terminal, 
since messages from one might 
overwrite or obscure messages 
from the other. Similarly, two 
tasks cannot be allowed to per¬ 
form an update on a transaction 
file at the same time, since the 
result of one operation might not 
be interpreted properly by the 
other. The management of critical 
resources is one of the most 
important jobs for a multitasking 
operating system. If done ineffi¬ 
ciently, total system speed may 
slow to little more than the rate 
at which jobs could be done se¬ 
quentially. 

data reduction —the extraction 
of information from raw data by 
the application of arithmetic and 
statistical transformations, or by 
the use of other mathematical 
methods. One of the goals of 
many real-time systems is to do 
any necessary data reduction at 
rates sufficient to allow process¬ 
ing to keep up with the arrival of 
data—by using a small amount of 
buffering if necessary. UNIX sys¬ 
tems are often used for data 
reduction, especially by micro or 
minicomputers that feed main¬ 
frames with “cooked data” ready 
for further analysis. 

deterministic interrupt laten¬ 


cy —a defined—or computable— 
interval between the time an 
interrupt signal arrives and the 
time it is serviced. Deterministic 
latencies, or at least bound laten¬ 
cies (where the maximum delay is 
known), are necessary for most 
types of real-time control sys¬ 
tems. Deterministic interrupt la¬ 
tencies normally are provided 
only on systems designed for 
process control or very simple 
use. 

disk striping —a technique for 
increasing disk system transfer 
rates by using several disk drives 
in parallel to record and play back 
some of the bits in a multibit data 
word. By using eight disks, for 
example, transfer speeds can be 
increased by a factor of eight over 
the rates offered by the single¬ 
disk solution. Disk striping also 
raises the effective maximum vol¬ 
ume size, since data is evenly 
spread between multiple disks. 

FLOPS —an acronym for “float¬ 
ing point operations per second”, 
more commonly measured nowa¬ 
days as “megaflops” or “giga¬ 
flops”. Because floating point cal¬ 
culations are more time con¬ 
suming than ordinary integer 
arithmetic, and since they are so 
commonly used in scientific and 
control applications, a megaflops 
rating is often more significant 
than a MIPS (million instruction 
per second) measurement. 

GPIB—initials that stand for 
“General Purpose Interface Bus”, 
a connection often used in refer¬ 
ence to the linking of electronic 
instruments for scientific testing 
and industrial work. The GPIB 
bus, which provides for “talk¬ 
ers”, “listeners”, and “control¬ 
lers” on an 8-bit wide parallel 
bus, is most frequently driven by 
a simple dedicated system, but 
some UNIX-based minis and mi¬ 
cros have also been called into 
service. GPIB is the IEEE 488 


standard, also known as HP-IB. 

host —in a computer system 
made up of a main processor and 
one or more attached proces¬ 
sors (such as array processors ), 
“host” refers to the main pro¬ 
cessing unit. In some configura¬ 
tions, the host might be a UNIX- 
driven system with the other 
processors treated as peripherals. 

interrupt-driven —said of sys¬ 
tems or software that respond to 
signals marking events. The al¬ 
ternatives would be to execute 
routines at fixed intervals or 
detect inputs by regularly moni¬ 
toring input lines. The UNIX 
kernel is interrupt-driven. 


interrupt handler —a routine 
called in response to a signal 


-. 

UNIX 

JOBS 

REGISTRY 

National registry of candi¬ 
dates and jobs in the Unix 
field. Please give us a call; 
send a resume; or request a 
free Resume Workbook & 
Career Planner. We are a 
professional employment 
firm managed by graduate 
engineers. 

800-231-5920 

P.O. Box 19949, Dept. UR 
Houston, TX 77224 
713-496-6100 


Scientific Placement, Inc. 

Unix is a trademark of Bel! Labs 
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marking an internal or external 
event requiring attention. UNIX 
has many interrupt handlers 
built into the kernel, but others 
often are added to respond to 
specific hardware configurations. 
Efficient interrupt handling and 
the assurance that delays will not 
exceed a maximum time are par¬ 
ticularly important in process 
control work. 

low-level parallelism —said of 
computer architectures that keep 
multiple copies of certain re¬ 
sources inside the CPU, in con¬ 
trast to the normal parallel strat¬ 
egy of providing complete mul¬ 
tiple processors. The low-level 
parallelism approach is becoming 
popular for RISC (“reduced in¬ 
struction set computers”). 

MIPS —short for “million in¬ 
structions per second”, a mea¬ 
surement for specifying the speed 
at which a computer or system 
can execute programs. Naturally, 
since some instructions execute 
faster than others, the particular 
benchmark used to arrive at this 
figure is significant. 

monte carlo analysis —a tech¬ 
nique for assessing the perfor¬ 
mance or operation of systems. 
Based on statistical measures of a 
large number of events that each 
use a random starting value or 
position, monte carlo analysis is 
widely used in simulation work. 

number crunching —the infor¬ 
mal name for the processing of 
large amounts of numerical data, 
especially data in floating point or 
other complex forms. Computers 
designed for number crunching 
are likely to be different in archi¬ 
tecture, software, and peripher¬ 
als from those designed for soft¬ 
ware development or commercial 
use. UNIX, of course, traditionally 
has been used for software de¬ 
velopment. 

optimizing compiler — a pro¬ 


gram that translates a high-level 
language into machine language, 
and—as part of that transla¬ 
tion—takes steps to increase the 
efficiency of the code. Typically, 
this involves making one or more 
extra passes during the transla¬ 
tion to determine how registers 
and other scarce system re¬ 
sources might best be used. 

overrun —a loss of data that 
occurs when a receiving system 
accepts a new signal before it has 
finished receiving an earlier one. 
UNIX systems used in data-col- 
lection applications are prone 
to occasional overruns because 
their interrupt processing can 
take varying amounts of time. 
The buffering of inputs helps, but 
good design generally calls for 
some kind of error checking or 
data recording if every input is 
expected to be crucial. 

parallelization — the decompo¬ 
sition of a computational task 
into portions that can be han¬ 
dled simultaneously by different 
processors. Unlike vectorization, 
parallelization does not imply 
that all apportioned tasks will be 
identical. 

physical memory —the amount 
of memory actually present in 
directly-accessible form. See vir¬ 
tual memory. 

poll —a check for a message or 
any other call for attention. Some 
simple microcomputer systems 
still poll their input ports to check 
for inputs, but most systems now 
are interrupt-driven instead. 

real time —a system designed to 
respond to outside events, and to 
service them as need be. Depend¬ 
ing on the needs of the equipment 
or processes being controlled, 
this may require response speeds 
as fast as a few microseconds. 

An older meaning of real time 
was used to describe those com¬ 
puter systems fast enough to be 


interactive, in order to distin¬ 
guish such systems from those 
that performed batch processing. 

RISC —an acronym for “reduced 
instruction set computer”, a type 
of processor architecture that at¬ 
tempts to achieve faster process¬ 
ing by implementing arrays of 
processors each with only simple 
instructions. RISC machines are 
becoming increasingly popular 
for scientific and engineering 
applications. 

vectorization —the division of a 
computational task into many 
identical subtasks that can be 
performed by an array processor 
or some other processing system 
capable of handling multiple 
similar operations at the same 
time. Not all problems are suit¬ 
able for vectorization, but—with 
the proper hardware—those that 
are can be run many times faster. 

virtual memory —a feature that 
simulates large amounts of phys¬ 
ical memory by swapping data 
back and forth between main 
memory and a disk storage sys¬ 
tem. One of the principal aims 
behind the development of the 
Berkeley distribution of UNIX 
was to add support for virtual 
memory to the existing version of 
Research UNIX. Many scientific 
applications—particularly those 
involving graphics, image pro¬ 
cessing, and data reduction— 
require the large memory address 
space that virtual memory pro¬ 
vides. 

If you have comments , ques¬ 
tions . or corrections to offer, 
please send them to Rosen¬ 
thal's UNIX Glossary , Box 9291 , 
Berkeley , CA 94709. 


Steve Rosenthal is a lexicogra¬ 
pher and writer living in Berkeley. 
His columns appear regularly in six 
microcomputer magazines. ■ 
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1986 Winter USENIX Technical Conference 
Marriott Hotel — City Center, Denver, Colorado 

January 15-17,1986 


TUTORIALS 

For each topic area, there will be related tutorials 
on adjacent days, concurrent with the other 
technical sessions. Tutorials of general interest 
will also be held. Possible topics include: 

• Ada Programming Language & 
Environment 

• Window System Implementation 

• SNA Networking & UNIX* 

• UNIX System Internals 

• UNIX Interprocess Communication, 
and others 

Tutorial speakers will be highly qualified 
technical experts who are able to give an 
indepth presentation. 


THE SPONSOR 

For the latest in UNIX applications and research, 
people look to USENIX, a not-for-profit association 
of individuals and institutions dedicated to 
fostering the development and communication 
of UNIX and UNIX-like systems and the C 
programming language. USENIX sponsors 
technical conferences, produces and distributes 
a newsletter and serves as coordinator of a 
software exchange for appropriately licensed 
members. 


THE TECHNICAL SESSIONS 

The 1986 Winter USENIX Conference will consist 
of workshop-oriented technical sessions in 
three topic areas: 

WINDOW ENVIRONMENTS AND UNIX 
WEDNESDAY, JANUARY 15, 1986 
A thorough exploration of the design and 
integration of UNIX-based window systems 
and their applications. 

UNIX ON BIG IRON 
THURSDAY, JANUARY 16,1986 
An analysis of issues raised by the imple¬ 
mentation and operation of UNIX on very 
large, powerful mainframes, including 
those with multiple processors. 

ADA AND THE UNIX SYSTEM 
FRIDAY, JANUARY 17, 1986 
An examination of the Ada language and 
its relationship to the UNIX system. 


For complete conference information, call: 
(213) 592-3243 or (213) 592-1381 

Or write: 

USENIX Conference Office 
P.O. Box 385 

Sunset Beach, CA 90742 
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RECENT 

RELEASES 


MATURITY COMES 
WITH AGE 

Western cultures exalt youth 
and often regard advancing age 
with horror. Eastern cultures, 
though, are known for placing 
value in age, considering that 
with experience comes maturity 
and wisdom. The computer in¬ 
dustry usually takes a Western 
perspective when it comes to 
software, thinking that oldy soft¬ 
ware must mean moldy software. 
Perhaps UNIX teaches us to take 
a lesson from the East—the sys¬ 
tem is old, but it has been main¬ 
tained over the years to serve 
current computer users’ needs. 
Another piece of software, Mac- 
syma (“macksimma”), is making 
the same claim. 

Since it has been under con¬ 
tinuous development at the Mas¬ 
sachusetts Institute of Technol¬ 
ogy from the late ’60s to 1982 and 
from 1982 to the present at 
Symbolics, Inc., Macsyma repre¬ 
sents about 150 programmer- 
years of software design. 

Symbolics now has released an 
enhanced version of Macsyma. 
As a computer algebra system 
used to assist scientists and engi¬ 
neers in solving complex math¬ 
ematical problems, it boasts more 
than 450 licensees worldwide, 
making it the most widely used 
system of its kind. It is capable 
of solving integration, differen¬ 
tiation, Taylor series, matrix 
manipulations, tensor analysis, 
differential equations, and other 
mathematical problems requiring 
advanced calculus capabilities. 
The new release incorporates 
code developed by Macsyma users 


working in product design and 
systems analysis applications 
areas as diverse as acoustics, 
VLSI circuit design, and econ¬ 
ometrics. 

Macsyma and UNIX, however, 
have more in common than just 
their age and diversity of use. Use 
of Macsyma contributed greatly to 
Lisp being ported and ultimately 
integrated into 4.2BSD. Though 
initially available only on the non- 
UNIX-running Symbolics 3600 
family of computers, as of this 
month the new version of Mac¬ 
syma can be licensed for use on 
Sun-2 micros and will soon be 
available on other UNIX-based 
workstations. The package is also 
used on minis, including DEC 
VAXen. 

Macsyma is marketed exclu¬ 
sively by Symbolics. For a work¬ 
station, a commercial license is 
$7500, and a license for govern- 
ment/non-profit organizations is 
85250. For a VAX, a commercial 
license costs $15,000, a govern¬ 
ment/non-profit license, $6000. 

On a VAX, Macsyma requires 
1.75 MB of memory for the first 
user and .75 MB for each simulta¬ 
neous user. About 10 MB of disk 
storage are required to store Mac- 
syma’s executable libraries. 

Symbolics, Inc., 11 Cambridge 
Center, Cambridge, MA 02142. 
617/577-7350. 

Circle No. 282 on Inquiry Card 

RTI AT MIT, TOO 

An ongoing endeavor at MIT of 
interest to UNIX users is Project 
Athena—a major, campus-wide, 
UNIX-based program designed to 


integrate modern computer and 
communications capabilities in¬ 
to all phases of the education¬ 
al process. Athena’s principal 
goal is to help students learn 
more creatively in a wide range 
of disciplines, and to help im¬ 
prove and refine MIT’s teaching 
methods. 

Participating in this project 
is Relational Technology, Inc. 
(RTI), which announced that its 
Ingres relational database man¬ 
agement and application develop¬ 
ment system has been selected 
as the foundation data manage¬ 
ment product for Project Athena. 
RTFs principal product, Ingres 
is sold complete with a collection 
of visual programming tools for 
accessing and displaying data 
and for building online interac¬ 
tive applications. These tools 
are designed to allow users to 
prototype and develop multi¬ 
user, shared database applica¬ 
tions without conventional pro¬ 
gramming. Multiple levels of re¬ 
port writing and graphics are 
available. RTFs networking tool, 
Ingres/NET, gives users corpo¬ 
rate-wide access to remote data¬ 
bases located on any computer in 
a network. 

Relational Technology, Inc., 
1080 Marina Village Parkway, 
Alameda, CA 94501. 415/769- 
1400. 
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HARRIS HIGH ON HCX 

Harris Corp. has announced a 
UNIX-based line of superminis 
that make use of 32-bit architec¬ 
ture. Entitled HCX (“Harris Com- 
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puter for UNIX”), the series 
makes its debut with the model 
HCX-7, which according to the 
Whetstone benchmark achieves 
7.1 MIPS performance. 

The HCX-7 operates under 
System V with Berkeley enhance¬ 
ments, and features reduced in¬ 
struction set computer (RISC) in¬ 
novations (160 total instructions) 
that typically require one ma¬ 
chine cycle of 100 nanoseconds to 
execute. It comes with a five- 
board CPU with Schottky bit-slice 
technology, 32-bit addressing, 
and three-stage instruction pipe¬ 
lining. This model supports up to 
32 MB of memory. 

The base configuration price 
for the HCX-7 is $225,000, which 
buys 2 MB of main memory, a 
battery backup unit, a communi¬ 
cations interface for 27 termi¬ 
nals, and a 32-user UNIX license. 
Adding 2 MB more of memory, a 
floating point processor, and an 1/ 
O expansion cabinet raises the 
price to $275,000. 

Harris Corp., Computer Sys¬ 
tems Division, 2101 W. Cypress 
Creek Rd., Ft. Lauderdale, FL 
33309-1892. 305/973-5125. 
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AH, SO, UNIX 

AT&T and UniSoft Systems of 
Berkeley, CA, have entered into 
an agreement whereby the com¬ 
panies will jointly develop an 
interface between Kanji applica¬ 
tions and System V running on 
AT&T’s 3B series of computers. 

AT&T UNIX Pacific Co., Ltd. 
(AT&T’s UNIX software subsid¬ 
iary in Japan), UniSoft, Nippon 
UniSoft (UniSoft’s Japanese re¬ 
presentative), and Argo 21 (a 
Japanese software house helping 
in the effort) will be working in 
Tokyo on a 3B2/400 to develop 
the interface, which should be 
completed by early 1986, and 
AT&T plans to license the soft¬ 
ware in source code worldwide 



Break through the PC/UNIX* barrier! 


At last. A product that guarantees clear passage from IBM PC’s and 
PC-Compatibles to UNIX — without unnecessary roadblocks. 

DaTapaSS is quick and simple. No clutter, no confusion: Just a direct 
path to the features you need most. Features like terminal emulation. 
Full access to DOS functions. Error-free uploading and downloading 
across public networks, LAN’s, or phone lines. Automatic restart and 
recovery of interrupted transfers. Key-selectable signon sequences. 
Softkeys you can program from DOS or UNIX to automate repeat 
transactions. It even lets you talk to other PC’s . . . and Honeywell 
mainframes, too. 

Interested? Give us a call for more information about DaTapaSS: 
your best route to error-free PC-to-UNIX communications. 



DTSS Incorporated 

Buck Hoad • Box 70 • Hanover, NH 0075;") • 000 040-0000 
A Subsidiary of Metropolitan Life Insurance Company 

* UNIX is a trademark of AT&T Bell l<al>oratnrics. IBM is a 
trademark of International Business Machines Corporation. 
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FORTRAN 77 


COMPILER INCLUDES FULL SUPPORT FOR MOTOROLA’S 


MC68020/68881 


• Full ANSI 77 implementation 

• Full Screen Source Level Symbolic Debugger 

• Unix and C Interface (Unix is a trademark of AT&T) 

• Generates 68000 and 68010 Code 

• Support for NS32081 and SKY FFP Math Hardware 


ALSO AVAILABLE 68020/68881 MACRO ASSEMBLER 


• 100% Motorola Compatible - Includes C Interface 

• 2X to 20X Faster Than Most Assemblers 


abssift 


SCIENTIFIC/ENGINEERING 
SOFTWARE 4268 N. Woodward 
Royal Oak. Michigan 48072 
(313) 54V-7111 • TX 23S608 
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U RECENT RELEASES 


MULTIUSER 

SYSTEMS? 


USE THE MULTIPORT " SOLUTION 

• Connect up to 8 terminals to an 
IBM PC for under $100 per 
connection 

• Network PC's together using inex¬ 
pensive serial ports instead of high- 

priced cards 

• Kits compatible with XENIX, PICK, 
BOS, THEOS, VENIX/86, PC-SHARE, 

& EasyLAN 

FREE Technical Assistance! 

Call (615) 254-0646 

RRNET 

The Multiuser Experts 

476 Woodycrest Ave Nashville. TN 37210/TELEX 332762 
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ASSEMBLERS 


We will support you on over 20 UNIX 
and Xenix based machines. Targets: 


Fairchild 

F8/3870 

Hitachi 

6301, 6305, HD64180 

Intel 

8041, 8048, 8051, 8080 
8086 family 

Motorola 

6800, 6801, 6805, 6809 
68HC11, 68000 family 

NSC 

800 

RCA 

1802 

Rockwell 

6502/65C02 

Texas Inst. 

TMS7000 

Zilog 

Z8, Z80 


UNII4*)RE™ 

SOFTWARE DEVELOPMENT SYSTEMS, INC. 
3110 Woodcreek Drive 

Downers Grove, IL 60515 U.S.A. (312) 971-8170 
England: Unit C, Ltd. (0903) 205233 

UNIX is a Trademark of AT&T Bell Labs 
Xenix is a Trademark of Microsoft 
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and offer binary versions on the 
3B line through Japanese distrib¬ 
utors. AT&T UNIX Pacific will 
coordinate the project while Uni- 
Soft will develop most of the 
software. 

The project’s purpose is not to 
accommodate translation per se, 
but to allow Japanese end users 
to make use of UNIX. Japanese 
users will be able to interface 
with System V in English using 
Roman characters or in Japanese 
using Kata-Kana characters, 
a phonetic alphabet commonly 
used in Japan. To support Japa¬ 
nese language input, the inter¬ 
face will allow a user to access 
an electronic dictionary of sever¬ 
al thousand graphics-oriented 
Kanji characters. After the user 
has typed in text in Roman or 
Kata-Kana characters using a 
conventional keyboard, UNIX 
software will check the online 
dictionary and return with one or 
more appropriate Kanji charac¬ 
ters. The user then will be able to 
select the appropriate character 
depending on the context of the 
sentence. 


Save Time and Money 
on Data Entry 

Use ZIPLIST to automatically 
look up city, state and county infor¬ 
mation based on zip code. Table of 
48,000 zips allows significant sav¬ 
ings on data entry, error correc¬ 
tions and file maintenance. This set 
of floppy disks, including easy in¬ 
structions, is just $149. Most 
popular 5 l A" and 8” formats are 
available. Hard disk recommended. 
Call or write for free information. 

DCC Data Service 

1990 M Street, N.W. Suite 610 
Washington, D.C. 20036 

Call toll-free 1-800-431-2577 
In DC & AK 202-452-1419 
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UniSoft already has a Kanji 
interface on its UniPlus version of 
UNIX, according to Robert Acker¬ 
man, UniSoft senior vice presi¬ 
dent. “This project is of special 
note because the technology in¬ 
volved in bringing a Kanji in¬ 
terface of UNIX to Japan can 
be translated [so to speak] to 
other such graphics-oriented al¬ 
phabets,” he said. 

UniSoft Systems, 739 Allston 
Way, Berkeley, CA 94710. 415/ 
644-1230. 
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MUMPS IS SPREADING 

Massachusetts General Hospi¬ 
tal is famous for many contribu¬ 
tion to the medical world, but its 
contribution to the computer pro¬ 
gramming world is gaining pop¬ 
ularity, too. MUMPS, that is, 
Massachusetts General Hospital 
Utility Multiprogramming Sys¬ 
tems, is an ANSI standard 
language developed at the pres¬ 
tigious institution under govern¬ 
ment contract. Motorola has 
announced that it is offering the 
Micronetics Standard MUMPS 
(MSM) with its Series 6000 and 
2000 UNIX-based systems. These 
two series consist of 32-bit ma¬ 
chines based on the Motorola 
68010 processor and running 
Motorola’s version of System V 
with Berkeley enhancements. 

MUMPS offers software devel¬ 
opment and debugging tools in¬ 
cluding good trace capabilities 
and a program editor; it also 
executes like an interpretative 
language. Now available, the 
MUMPS licensing fee starts at 
$1995. 

Motorola Four-Phase Systems, 
10700 N. DeAnza Blvd., Cuper¬ 
tino, CA 95014. 408/255-0900. 
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UNIX™ APPLICATION 
DEVELOPMENT 

TODAY is far more than the 
awkward collection of tricks and 
tools that are often labelled 
“4GL”. TODAY provides a 

COMPLETE application 
development environment that 
will revolutionize the way you 
develop and maintain applications. 

No UNIX* systems knowledge 
is necessary. 

Let’s put it frankly: developing 
an application is a costly pro¬ 
position. You’ll need a highly 
skilled team of designers, analysts 
and programmers, and several 
man-years to get things off the 
ground. And that’s not to mention 
the on-going costs of documenta¬ 
tion, customization and 
maintenance! 

TODAY tackles these problems 
through a new methodology with 
high performance architecture 
and a comprehensive range of 
features. It’s so quick and easy to 
use that TODAY developers can 
do the whole job—design, 
analysis, development and 
documentation. 

TODAY provides a compre¬ 
hensive range of features that 
keep application building easy 
while optimizing development 
resources: 

• Powerful recursive logic and 
Decision Tables 

• Synonyms, Menus, Prompts, 
Helps and Defaults for 
streamlined definitions 

• Screen Painter 

• A Report Generator which 
includes a Painter 


Cure for Backlogs 
Induced by 3GLs 

in EDP Departments, 
Software Houses 
& Others 




Push-button Self¬ 
documentation 
Audit Trails 

Source-code security through 
run-time only configurations 
• Developed Applications 
instantly portable across 
UNIX* systems 
Because definitions are 
Dictionary-based, any changes 
are easily made in one central 
location. A key feature, 
“tailoring” lets you alter an 
application — perhaps to 
customize it for a particular site 
or user — without affecting the 
original version. If required, 
applications can be set up as 
Models (Prototypes) and later 
enhanced to grow and change 
with the business. Tailoring 
versions is the perfect solution for 
quickly generating multiple 
applications based on one Model. 

TODAY runs under UNIX* or 
UNIX*-compatible operating 
systems on super-mini down to 
micro business computers using 
any of a range of databases. And 
if that's not enough, TODAY is 
backed by 14 man-years of 
research and development and 
the confidence of users who are 
breaking time zones in software 
development. 

See us at Comdex, Nov. 20-24, 
Booth #434 


bbj Computer Services, Inc. 
2946 Scott Blvd. 

Santa Clara, CA 95054 
Telephone: (408) 727-4464 
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THE S SYSTEM 


THE S SYSTEM 

Continued from page 59 

translate users' requests from the terminology of 
specific applications into the S expressions that 
generate the results. 

Less frequently, more ambitious projects have 
included user-written S functions or interfaces 
between S and other large application systems. The 
relative simplicity of writing S macros means that a 
new system tailored to a particular user community 
can be written with a fraction of the programming 
effort required for a corresponding project using a 
general programming language. Also, the system 
development effort grows naturally (often uninten¬ 
tionally at first) out of direct use of S to solve user 
problems; there is no large initial investment in 
programming before any of the proposed uses can be 
tested and evaluated. 

One of the more difficult tasks in user training 
has been convincing Fortran programmers that it is 
ordinarily not necessary to write explicit loops to 
operate on collections of data. Most non-program¬ 
mers, however, seem to have little difficulty with the 
implicit iteration provided by S. 


New from Image Network! 

Documenter’s Workbench® 

for laserprinters and typesetters. 

DWB is troff, eqn, tbl, and pic 
interfaced to raster printing devices. 

Our existing XROFF product allows DWB 
to work with the following systems and printers: 

• System III 

• V7 

• VAX/VMS 

• Amdahl/UTS 

• Xenix 

• UNOS 

• Xerox 2700, 3700 

• Xerox 8700, 9700 


• System V 

• Berkeley 4.2 

• VAX/Ultrix 

• IBM/PC MSI DOS 

• Eunice 

• Uni Plus + 

• DEC LNOIs, LN03 

• APS-5 typesetter 

• Compugraphic 8400 


Use DWB with a laser primer to make high quality 
documents or to make proof copies before typesetting. 

Call or write to tell us your printing requirements! 
Image Network, ( 4 i 5 ) 967-0542 

448 Middlefield Road, Mountain View, CA 94043 

*Docu«cwtw*s Workbench is a trademark »f AT& I Bell l-ahoraioncv_ 


Circle No. 285 on Inquiry Card 


Specific user suggestions and our general recog¬ 
nition of the pattern of use have contributed many 
of the enhancements in S. An early user suggestion 
was the inclusion of a right-facing assignment 
arrow (->) for the occasion when one decides to save 
a result after typing a long expression. Our use of 
tools like syntax-driven parsing makes such 
changes easy. Interestingly, the interactive use of S 
in this case has direct implications for the syntax. 
Other enhancements that respond to user needs 
include: a simple mechanism to edit and rerun 
expressions after errors; a “diary" feature to 
provide a history of the expressions executed during 
a session; tools to help users create online documen¬ 
tation for their macros, datasets, and new S 
functions; and facilities for moving large collections 
of S datasets among different machines in a 
portable way. We have also provided a mechanism 
for running S noninteractively for large or repetitive 
analyses, and a technique for creating device¬ 
independent graphics metafiles that can be plotted 
later on interactive devices or batch devices. The 
ability to provide such facilities with only a limited 
expenditure of our own time derives from our 
modular, tool-oriented design, and from the similar 
orientation of the UNIX environment. 

FUTURE PLANS 

Future plans for S concentrate on improving the 
human interface, particularly for use with the new 
generation of workstations. We have made quite a 
bit of progress in utilizing the windows, mouse, and 
processor of the Teletype 5620 Terminal to produce 
dynamic graphics displays. These features also 
allow design of non-programming interfaces to data 
analysis, with greater flexibility and more sophisti¬ 
cated user support than was previously possible. 


Richard Becker is a Member of Technical Staff in the 
Statistics and Data Analysis Research Department at 
AT&T Bell Laboratories. His research interests include 
system design, graphics, data analysis, and worksta¬ 
tions. He and John Chambers are coauthors of S: An 
Interactive Environment for Data Analysis and Graphics 
and Extending the S System. 

John Chambers is Head of the Statistics and Data 
Analysis Research Department at AT&T Bell Laborato¬ 
ries. His research interests include system design, 
graphics, numerical analysis, symbolic computation, 
and expert software. He is the author of Computational 
Methods for Data Analysis and coauthor of Graphical 
Methods for Data Analysis. ■ 

Copyright 1984. Association for Computing Machinery. Inc., by 
permission. 
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REAL-TIME UNIX 

Continued from page 67 
AST to real-time processes. The 
work on the scheduler and the 
memory-locking primitives per¬ 
mits response to be sufficiently 
“instantaneous” and predictable 
for a wide class of real-time 
applications. In UNOS, the use of 
eventcounts alone solves the 
same problems. 

THE UNWRITTEN 
REQUIREMENT 

Our discussion of the seven 
requirements would be hollow, 
however, if we didn’t consider the 
practical requirements of the 
marketplace. Most current real¬ 
time programs are written in 
either assembly language or some 
variant of Fortran, so the market 
demands that these programs 
be kept working for as long as 
possible. 

In the case of assembly lan¬ 
guage programs, little needs to be 
done. To a large extent, C already 
is doing the job once handled by 
assembler. And since C is avail¬ 
able on almost all commercial 
architectures, a complete transi¬ 
tion seems assured. 

C programmers, though, are 
notorious for their disdain for 
Fortran. Because UNIX is written 
in C and because many Fortran 
programmers quickly embraced 
the new language, Fortran was 
often ignored in early UNIX imple¬ 
mentations. Despite this disdain, 
the real-time market requires 
that a “production quality” For¬ 
tran accompany any real-time 
operating system. Like it or not, 
UNIX developers have come to 
acknowledge that Fortran contin¬ 
ues to be the primary language 
used today for the analysis of 
data. Many installations have a 
large investment in existing For¬ 
tran programs. Unsurprisingly, 
they are unwilling to rewrite 
these programs simply to take 
advantage of the superior support 


UNIX offers for C. 

Companies that serve this 
market have taken notice [4]. We 
believe that as the real-time pro¬ 
gramming community comes to 
embrace UNIX, it will move away 
from Fortran and switch to more 
modern languages such as C. But 
we also believe that implementa¬ 
tions of Fortran will continue to 
be important for real-time work, 
and that they will continue to 
improve for some time to come. 

UNIX IN REAL TIME: 
ADVANTAGES AND 
TRADEOFFS 

As UNIX has migrated into the 
Real-Time World , it has changed 
in unmistakable ways. What has 
been gained and what has been 
lost? 

What have we gained? All 
real-time programs must be writ¬ 
ten by a programmer, but real¬ 
time operating systems are often 
difficult systems to use for writ¬ 
ing programs. For example, Digi¬ 
tal’s RT-11 and RSX-11 are rich 
in real-time features, but they 
lack the ease of use that UNIX is 
built around. The UNIX para¬ 
digm of using many small, simple 
programs to tackle big tasks 
has proven particularly valuable. 
UNIX also is unsurpassed for its 
wide range of available utilities. 
This is directly attributable to 
thousands of hours of tuning and 
“hacking” in the universities and 
companies where UNIX is used. 
One interesting note is that one of 
the best source language debug¬ 
gers available for any operating 
system was developed for UNIX at 
a university, and has since be¬ 
come the basis for many commer¬ 
cial debuggers [6]. 

With UNIX you “get it all”. One 
of the biggest problems a new 
UNIX user has comes in sorting 
out the myriad of choices. In 
addition to the usual compilers, 
linkers, and text editors, the sys¬ 
tem also contains presentation 


graphics programs, documenta¬ 
tion development programs, and 
support for a wide range of peri¬ 
pherals. While a new RT-11 user 
might spend hours figuring out 
the only way to display a particu¬ 
lar character sequence, a new 
UNIX user probably could spend 
the same amount of time figuring 
out the easiest way. 

The entry of UNIX into the real¬ 
time world has brought choices to 
the programmer and user that 
never existed before. 

What have we lost? Nothing, 
of course, comes without cost. 
One of the great UNIX concepts is 
the idea that a program can be 
“re-used”. In many cases, this 
means “ported” or moved from 
one UNIX system to another. 
Although this applies to most 
well-written utilities, real-time 
programs tend to be specific to a 
certain task. Since there is no 
single conventional way to han¬ 
dle the “real-time” nature of a 
program, any UNIX software us¬ 
ing the real-time extensions of 
one manufacturer is liable to run 
into problems if it’s “ported” to 
another UNIX implementation. 
This, of course, is why many 
UNIX manufacturers are part of 
the IEEE PI003 committee to 
produce a standardized UNIX in¬ 
terface. It’s hoped that through 
efforts such as these, real-time 
extensions may come to be as 
well defined as the read(2) and 
write(2) system calls currently 
are. 

Apart from restrictions on por¬ 
tability, though, another problem 
afflicts real-time UNIX imple¬ 
mentations. Whenever a real¬ 
time process is running, UNIX 
must quit acting like a timeshar¬ 
ing system, where all processes 
are equal. A real-time process will 
tend to “hog” the resources it 
needs and, as a result, slow down 
other work on the machine. In 
fact, this is exactly what is 
supposed to happen, but tell that 
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to the lowly user waiting for a 
simple job to finish. 

Space is another problem in 
the real-time realm. Real-time 
applications often do not need all 
of the “hooks” UNIX must keep in 
memory. There was a day when 
UNIX could run on 64 KB of 
memory; this included the entire 
operating system and all of a 
user’s programs. These old sys¬ 
tems may have been slow, but 
by comparison with today’s 
UNIX implementations—many of 
which can hardly fit into 1 MB of 
memory—they seem impressive¬ 
ly lean. To be fair, today’s UNIX 
has grown into a system that 
offers much more flexibility and 
functionality than any of its pre¬ 
decessors, but along the way it 
has also put on some ungainly 
weight. 

WHAT NEXT? 

Adapting UNIX for real-time is 
an endless task. Among the many 
changes that could still be made 
we list two: block common data 
and lightweight processes. 

Block Common Data. As men¬ 
tioned previously, Fortran tends 
to be the programming language 
of choice for many real-time pro¬ 
grammers. One structure com¬ 
monly found in real-time Fortran 
is block common data , which 
makes available to a set of pro¬ 
cesses a “common block” resid¬ 
ing in memory at a specific loca¬ 
tion. This language structure 
allows a hunk of data to be shared 
between multiple processes much 
like regular shared memory. Un¬ 
der block common data, each 
process uses the same “name” 
for a common block. Though each 
process has its own address for 
the block, all the processes share 
the block by name. An interesting 
aspect of this structure is that 
shared memory remains intact 
after a process terminates. That 
is, the first process that tries to 
access the shared memory causes 


the data space to be created. 
Other processes may access that 
area, and the common area will 
not be removed until it is explicit¬ 
ly released by a program or until 
the machine is rebooted. 

Unfortunately, block common 
data is a hard structure to imple¬ 
ment under UNIX. Why? The 
answer lies in the format of the 
a.out file. This file contains two 
major regions: raw program text 
and static data. It also includes a 
special segment called bss that is 
allocated at runtime. (Veteran 
IBM programmers should recog¬ 
nize bss as an abbreviation for 
“block static storage”.) The text 
segment contains “read-only” 
instructions and program text. 
The data segment contains data 
that has been initialized to some 
value. The bss segment also 
serves as data storage that has 
not been pre-initialized but is 
allocated at program startup and 
initialized to the value of zero. 

Most operating systems sup¬ 
port text segments and provide 
for more than one data seg¬ 
ment and more than one bss seg¬ 
ment. These segments commonly 
are known as multiple dsects, 
csects, or psects (for data section, 
code section, or program section). 
Each of these sects is aligned by 
the linker and the operating sys¬ 
tem’s program loader (the exec(2) 
call of UNIX) to begin on a “suit¬ 
able” boundary, often a “page” of 
memory (where a “page” refers to 
the local machine’s primitive unit 
of data storage, usually between 
64 and 4096 bytes of data). The 
current UNIX linker, though, does 
not support this type of align¬ 
ment; the a.out format does not 
support multiple sections and, 
sigh, most UNIX kernel imple¬ 
mentations do not support seg¬ 
mented program layout. 

The changes required to sup¬ 
port block common data would be 
far reaching, affecting compilers, 
debuggers, and other program¬ 


ming utilities—as well as imple¬ 
mentations of the exec(2) system 
call. Nevertheless, we expect to 
see this type of change introduced 
someday. (To be fair, System V 
already has a new file format 
called COFF—for “common ob¬ 
ject file format”. This new binary 
format does address some of the 
problems of a.out, but there are 
others that are not confronted. 
Unfortunately, these problems 
cannot be discussed here since 
they could fill a paper of their 
own.) 

Lightweight Processes. Much 
has been said in the operating 
system community about how 
asynchronous events might be 
correctly handled [5]. Indeed, 
many “modern” programming 
languages like Ada now pro¬ 
vide support for more than one 
“thread of control” within a sin¬ 
gle process. This is so that they 
might accommodate asynchro¬ 
nous events. 

Each thread can be thought 
of as a subprocess or a pro¬ 
cess within a process. Since all 
“threads” share all resources 
(including address space) with 
their siblings, they can be sched¬ 
uled more efficiently than can full 
UNIX processes. 

Lightweight processes consist 
of implementations of multiple 
threads. Each thread shares text, 
data, and bss segments with its 
siblings. A common stack base 
exists for each process, but each 
thread has a different stack and 
uses different copies of whatever 
hardware is needed (such as reg¬ 
isters and pc) to run a “program” 
on the local CPU. 

Unfortunately, most proposals 
to add lightweight processes to 
UNIX have become ensnarled in 
arguments about the amount of 
support they require. The result 
is that these processes often end 
up as “heavy” as the full ones 
offered by UNIX. 

One implementation of a UNIX 
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look-alike called TRIX [11] from 
the Real Time Systems Laborato¬ 
ry at MIT uses lightweight pro¬ 
cesses for everything. However, 
the full UNIX semantics of the 
fork(2) and exec(2) primitives 
have been lost, meaning that 
TRIX does not look completely 
like UNIX for all possible pro¬ 
grams. Indeed, the porting of 
programs like the Bourne shell 
and C shell command inter¬ 
preters can be quite tricky under 
TRIX. 

CONCLUSION 

The UNIX system, brought into 
the world as a timesharing oper¬ 
ating system, nevertheless has 
been adapted to real-time appli¬ 
cations. In fact, because of its 
timesharing heritage, UNIX is 
rich in its support of multipro¬ 
cess work, simple communica¬ 
tion schemes, and the synchroni¬ 
zation of processes. 

Because seconds (classic time¬ 
sharing time slices) are much 
longer than milliseconds (classic 
real-time increments), some fa¬ 
cilities have had to be overhauled 
in order to function better in a 
more classic real-time system. 
But it is eminently reasonable to 
make these changes. The result, 
we contend, looks, feels, and 
works like UNIX—and retains 
the ease of use, excellent pro¬ 
gramming support, and docu¬ 
mentation preparation strengths 
that UNIX offers. 

Further work, of course, could 
make UNIX better still for real¬ 
time use. However, as demon¬ 
strated by commercially availa¬ 
ble implementations of real-time 
UNIX systems, the day of real¬ 
time UNIX already has arrived. 


Clement T. Cole is an Engineer¬ 
ing Supervisor at MASSCOMP. Pre¬ 
viously, he consulted nationally on 
UNIX-related issues, and worked 
for various firms, including Tek¬ 
tronix, Inc., and the Mellon Insti¬ 


tute of Science at Carnegie-Mellon 
University. Mr. Cole holds degrees in 
Electrical Engineering and Math¬ 
ematics from CMU, and has earned 
an MS in Computer Science from 
UC Berkeley. He currently serves as 
a member of the IEEE PI003 POSE 
(UNIX) Working Group. 

John Sundman is a Senior Tech¬ 
nical Writer at MASSCOMP. Like 
many technical writers, he entered 
the computer field by way of a back 
door. His formal education is in 
Agricultural Economics, with a con¬ 
centration on African farming sys¬ 
tems. ■ 
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CALENDAR 


EVENTS 

DECEMBER 

December 12-13 Monterey, CA: Usenix second annual graphics 
workshop. Contact: Usenix Conference Office. PO Box 385, 
Sunset Beach. CA 90742. 213/592-3243. 

JANUARY 1986 

January 15-17 Denver: Winter ‘86 Usenix Technical Confer¬ 
ence. Contact: Usenix Conference Office (see above). 

FEBRUARY 

February 4-7 Anaheim. CA: UniForum International Confer¬ 
ence of UNIX users, sponsored by /usr/group. Contact: 
UniForum 1986, 2400 E. Devon Ave., Suite 205, Des Plaines. IL 
60018. 312/299-3131. 

TRAINING 

Note: Below are listed the dates, locations, titles, and 
contacts for UNIX-related training courses. For registration 
and further information on particular courses, contact the 
firm cited. Training firm addresses and phone numbers are 
listed alphabetically at the end of the calendar. 

NOVEMBER 

November 4-5 Edison, NJ: ’‘Shell Programming”. Contact 
AUXCO. 

November 4-5 Santa Monica, CA: “Advanced Commands for 
Programmers”. Contact Interactive. 

November 4-6 Cherry Hill, NJ: “SNA Architecture and 
Implementation”. Contact CSI. 

November 4-8 Trumbull, CT: “Advanced C”. Contact Bunker 
Ramo. 

November 4-8 Cincinnati: ”C Shell Programming”. Contact 
IT DC. 

November 4-8 Washington. DC: ”C Language Workshop”. 
Contact Structured Methods. 

November 4-8 Chicago: “UNIX System Administration”. 
Contact Uniq. 

November 4-8 Washington. DC: “The UNIX System for the DP 
Professional”. Contact Webco. 

November 5-8 Washington. DC: “Programming in C”. Contact 
ICS. 

November 5-8 Los Angeles: “UNIX: A Comprehensive Introduc¬ 
tion”. Contact ICS. 

November 6-8 Edison, NJ: “UNIX Tools”. Contact AUXCO. 
November 6-8 Santa Monica, CA: “UNIX Architecture—A 
Conceptual Overview”. Contact Interactive. 

November 6-8 New York: “Fundamentals of the UNIX System 
for Management”. Contact LUCID. 

November 6-8 Bellevue, WA: “Hands-on UNIX for Program¬ 
mers”. Contact SSC. 


November 11-12 Tarrytown, NY: “C Data Concepts for 
Manager”. Contact Sessions and Gimpel. 

November 11-13 London: ‘‘UNIX Administration”. Contact 
CTG. 

November 11-13 New York: “Fundamentals of the UNIX 
System for Management”. Contact LUCID. 

November 11-15 Edison, NJ: “C-UNIX Interface”. Contact 
AUXCO. 

November 11-15 Trumbull, CT: “Intro to UNIX”. Contact 
Bunker Ramo. 

November 11-15 Dallas and San Francisco: “C Language 
Programming”. Contact CTG. 

November 11-15 New York and Washington, DC: “UNIX 
Internals”. Contact CTG. 

November 11-15 Santa Monica, CA: “The C Programming 
Language”. Contact Interactive. 

November 11-15 New York: “UNIX System Workshop”. 
Contact Structured Methods. 

November 11-15 Chicago: “C Language”. Contact Uniq. 
November 11-22 Cincinnati: “UNIX for Application Develop¬ 
ers”. Contact ITDC. 

November 12 Washington, DC: “UNIX vi editing”. Contact 
Webco. 

November 12-15 Los Angeles: “Programming in C”. Contact 
ICS. 

November 13-14 Washington, DC: “Advanced Editing”. 
Contact Webco. 

November 13-15 Austin, TX: “SNA Architecture and Imple¬ 
mentation”. Contact CSI. 

November 13-15 Tarrytown, NY: ‘‘C Data Concepts for 
Programmers”. Contact Sessions and Gimpel. 

November 15 Washington, DC: “Introduction to nroff”. 
Contact Webco. 

November 18-19 Dallas and San Francisco: “Shell Program¬ 
ming”. Contact CTG. 

November 18-19 London: “Advanced C Programming Work¬ 
shop”. Contact CTG. 

November 18-19 Santa Monica. CA: “Advanced Topics for C 
Programmers”. Contact Interactive. 

November 18-19 Annapolis, MD: “The Concepts of Object- 
Oriented Programming”. Contact PPI. 

November 18-20 New York: “Office Automation”. Contact 
LUCID. 

November 18-21 Edison, NJ: “System Administration”. 
Contact AUXCO. 

November 18-22 Trumbull, CT: ”C Programming”. Contact 
Bunker Ramo. 

November 18-22 Merrimack, NH: ”C Programming Work¬ 
shop”. Contact Plum Hall. 

November 18-22 New York: ”C Language Workshop”. Contact 
Structured Methods. 

November 18-22 Chicago: “Unify Database Management”. 
Contact Uniq. 

November 18-22 Washington, DC: ”C Language Program- 
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ming”. Contact Webco. 

November 19 Palo Alto, CA: SV Net Monthly Meeting. Contact 
SV Net. 

November 19-21 New York and Washington, DC: “UNIX 
Administration”. Contact CTG. 

November 20-22 London: “Advanced C Programming Under 
UNIX”. Contact CTG. 

November 20-22 Dallas and San Francisco: “Using Advanced 
UNIX Commands”. Contact CTG. 

November 20-22 “Advanced C Programming Under UNIX”. 
Contact Interactive. 

November 25 New York: “UNIX System Literacy”. Contact 
Structured Methods. 

November 25-26 New York: “Using Lex and yacc “. Contact 
Structured Methods. 

November 25-28 New York: “UNIX System Concepts and 
Facilities”. Contact LUCID. 

November 25-29 London: “Berkeley Fundamentals and esh 
Shell". Contact CTG. 

DECEMBER 

December 2 New York: “Mainframe-to-Mini-to-Micro Links”. 
Contact Interactive. 

December 2-3 New York and Washington, DC: “Advanced C 
Programming Workshop”. Contact CTG. 

December 2-3 New York: “Shell Programming Workshop”. 
Contact Structured Methods. 

December 2-4 Edison, NJ: “Advanced C Language Program¬ 
ming”. Contact AUXCO. 

December 2-4 Santa Monica, CA: “UNIX Fundamentals”. 
Contact Interactive. 

December 2-5 Callaway Gardens, GA: “UNIX OS: The First 
Step”. Contact AT&T 

December 2-6 Dallas and San Francisco: “UNIX Internals”. 
Contact CTG. 

December 2-6 Cincinnati: “UNIX for End Users”. Contact 
ITDC. 

December 2-6 Absecon, NJ: “C Programming Workshop”. 
Contact Plum Hall. 

December 2-6 Washington, DC: “C Language Programming". 
Contact Webco. 

December 3 London: “UNIX Overview". Contact CTG. 
December 3-5 San Francisco: “SNA Architecture and Imple¬ 
mentation”. Contact CSI. 

December 4-6 London: “UNIX Fundamentals for Non-Program¬ 
mers”. Contact CTG. 

December 4-6 New York and Washington, DC: “Advanced C 
Programming Under UNIX”. Contact CTG. 

December 5-6 Edison, NJ: “C Language Debugging”. Contact 
AUXCO. 

December 5-6 Santa Monica, CA: “Using the Shell". Contact 
Interactive. 

December 9 New York: “Principles of Computer Graphics". 
Contact LUCID. 

December 9-10 Santa Monica, CA: “System Administrator’s 
Overview". Contact Interactive. 


Please send announcements about training or events of 
interest to: UNIX Review Calendar. 500 Howard Street. San 
Francisco. CA 94105. Include the sponsor, date and location 
of event, address of contact, and relevant background 
information. 


CONTACT INFORMATION 


American Institute for Quality and Reliability (AIQR). 1494 
Hamilton Ave., Suite 104, San Jose. CA 95125. 800/621- 
0854 ext.290, or in CA. 408/978-2911. 

Asidor Training Institute. 2143 Morris Ave., Suite 5, 
Union. NJ 07083. 201/888-0241. 

AT&T Information Systems. Institute for Communications 
and Information Management. PO Box 8, Pine Mountain. 
GA 31822-0008. 800/247-1212. 

Auxton Computer Enterprises, Inc. (AUXCO). 2 Kilmer 
Rd., Edison. NJ 08817. 201/572-5075. 

Bunker Ramo Information Systems, Trumbull Industrial 
Park. Trumbull, CT 06609. 203/386-2000. 

Center for Advanced Professional Education (CAPE). 1820 
E. Garry St.. Suite 110. Santa Ana, CA 92705. 714/261- 
0240. 

Computer Technology Group (CTG), 310 S. Michigan 
Avenue. Chicago, IL 60604. 800/323-UNIX. or in IL, 312/ 
987-4082. 

Communications Solutions, Inc. (CSI). 992 S. Saratoga- 
Sunnyvale Road. San Jose. CA 95129. 408/725-1568. 

Information Technology Development Corp. (ITDC), 9952 
Pebbleknoll Drive, Cincinnati, OH 45247. 513/741-8968. 

Integrated Computer Systems (ICS), PO Box 45405, Los 
Angeles. CA 90045. 800/421-8166. or in CA. 800/352- 
8251. 

Interactive Systems Corp., 2401 Colorado Avenue, 3rd 
floor. Santa Monica, CA 90404. 213/453-8649. 

LUCID. 260 Fifth Avenue. Suite 901. New York, NY 10001. 
212/807-9444. 

Plum Hall. 1 Spruce Avenue, Cardiff, NJ 08232. 609/927- 
3770. 

Productivity Products International, Inc. (PPI), 27 Glen 
Road. Sandy Hook, CT 06482. 203/426-1875. 

Sessions & Gimpel Training Associates, 474 Washington 
Street. Holliston, MA 01746. 617/429-6350. 

Silicon Valley Net (SV Net). PO Box 700251. San Jose. CA 
95170-0251.415/594-2821 (Grant Rostig). 

Specialized Systems Consultants (SSC), PO Box 7, North- 
gate Station, Seattle, WA 98125-0007. 206/367-UNIX. 

Structured Methods, Inc., 7 W. 18th St., New York, NY 
10011.800/221-8274. 

Uni-Ops. PO Box 27097. Concord, CA 94527-0097. 415/ 
945-0448. 

Uniq Digital Technologies, 28 S. Water Street, Batavia, IL 
60510. 312/879-1008. 

Webco Industries, Inc.. 14918 Laurel Oaks Lane, Laurel, 
MI) 20707. 301/498-0722. 
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THE LAST 
WORD 


Letters to the editor 


SOFTWARE "DRIVER TRAINING" 

Dear UNIX REVIEW, 

In Glenn Groenewold’s Rales of 
the Game column in your July 
issue, he claims: “Even a com¬ 
pletely shielded [UNIX] system 
doesn’t approach the user ease of 
the modern automobile, where you 
need only turn the key and step on 
the gas.” In one sense he’s right; in 
another, he’s wrong. 

Mr. Groenewold has forgotten 
that driving is not a natural hu¬ 
man ability. One must learn to 
drive; this normally involves a good 
deal of time and effort, and prefer¬ 
ably the services of a skilled instructor. Trying to 
bypass this learning process is both unwise and 
illegal. Driving is taken so much for granted in our so¬ 
ciety that it’s easy to overlook the skill and training 
required. 

In this sense, current computer systems are 
already much easier to use than a modern auto¬ 
mobile. Learning to use most computer systems is no 
harder than learning touch typing, or arithmetic, or 
correct English spelling. What is different is the social 
acceptability of lengthy training processes. 

People do not want to make major efforts to learn to 
use a computer system, especially since every system 
is different. If computers become as ubiquitous as 
many people think, and there is a lot more standard¬ 
ization of the user interface, then eventually we may 
see detailed training in the use (not programming!) of 
computer systems become a standard part of educa¬ 
tion. Until then, all we can do is work to make 
inherently complex software systems simpler to use. 

Henry Spencer 
SP Systems 
Toronto, Ontario 


LEADER ZAPPED; 

NOW UNZAP 

Dear UNIX REVIEW, 

It was with mixed happiness 
and horror that I opened my June 
issue of UNIX REVIEW—happiness 
because my article “How it Should 
be Done’’ was prominently fea¬ 
tured (I even got my name in Mark 
Compton’s column!)—horror be¬ 
cause the name of one of the most 
important members of the Lucas- 
film Games Group was omitted 
entirely! David Fox was project 
leader for “Rescue on Fractalus!’’. 
The game was primarily David’s 
idea and without his efforts there would have been no 
such game. 

Unfortunately, the picture on page 38 of your June 
issue included everyone but David Fox (who was off 
zapping Jaggis while we were posing). To see what Da¬ 
vid Fox looks like, check the “Rescue on Fractalus!’’ 
cover picture in your local game store—that’s him in 
the orange flight suit. 

Peter Langston 
Bell Communications Research 
Morristown, NJ 

BEG TO DIFFER 

Dear UNIX REVIEW, 

Joel McCormack (UNIX REVIEW, September, 
1985, p. 31) comments, “There are currently no 
textbooks on Modula-2. . . I’m unsure what 
McCormack classifies as a “textbook”. The follow¬ 
ing most certainly exist: 

1) Interactive Programming Environments , by 
Barstow, Shrobe, and Sandewall (McGraw-Hill, 
1984); 
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2) Modula-2 for Pascal Programmers, by Gleaves 
(Springer-Verlag, 1984); 

3) Programming in Modula-2, 3rd ed., by Niklaus 
Wirth (Springer-Verlag, 1985); 

4) Software Engineering With Modula-2 and ADA, 
by Wiener and Sincovec (Wiley, 1984); 

5) Modula-2 Programming, by Ogilvie (McGraw-Hill, 
1985). 

Bill Freeman 
Tinton Falls, NJ 

Thank youfor bringing these resources to light. 
In a similar vein, it has been observed that a 
reference within the same article incorrectly 
indicated that tt Modula-2—A Solution to Pascals 
Problems ” by Sumner and Gleaves had run in the 
September, 1983, issue of S/GPLAN. The article in 
fact was printed in the September, 1982, issue of 
that publication. Editor 

GOT UP AND GONE 

Dear UNIX REVIEW, 

I wondered why, in the C Advisor (March 1985), 
Bill Tuthill felt it necessary to apologize for his use of 
gotos. Sure enough, in the June letters to the editor, 
the goto witch hunters were out in force. 

Just so there is no misunderstanding, I agree that 
the gotos of BASIC and Fortran are an abomination. 
Gotos in C, however, are seldom a problem. Those 
who claim that C gotos are just like Fortran gotos are 
chasing a straw man. 

Bill Tuthill, even if he never does anything else in 
his career, has long since “paid his dues” as a 
professional programmer. His instincts are right on 
target. 

Both letter writers would have us believe that the 
sample code is improved by turning it into a formal 
loop. That implies that the nature of the code 
fragment is iterative; it says that the programmer 
wants to emphasize that this is an iterative 
algorithm. 

The fact is that the code would normally be 
executed only once. Making a loop out of it is a smoke¬ 
screen that obscures the meaning. 

If the anti-goto folks are to be consistent, they’ll 
have to take on much more than just literal gotos. An 
obvious target is setjmp/longjmp (non-local gotos 
with automatic call frame abort). Exceptions also 
have to go; instead, all programs must have a main 
loop somewhat like the following; 

while ( ! divide_by_zero && ! illegaL_instruction && ! hangup etc. 

Of course, if any of these exceptions do occur, they 


must be passed back, not just one function at a time, 
but one level within each function at a time. 
Interrupts and pipelining are even worse—rather like 
three-dimensional gotos, out of the plane of the 
program listing. Can them too. And as for parallel 
processing —that’s like four-dimensional gotos! 
Anathema! 

I wonder what those guys make of the new ANSI C 
proposed storage class volatile—the one that warns 
the compiler that some other process may modify a 
data item? 

There is, in fact, a piece of very badly structured 
code in Bill’s example, which both letter writers 
missed. I refer to the “exit(l)”. Obviously some error 
has occurred. There is no diagnostic; there is no 
attempted cleanup. Instead, the program executes a 
longjmp with an unknown status to an unknown 
context, with a faint prayer (the “1”) that that context 
might do something sensible. Good luck. 

Dave Fafarman 
ENSCo Engineering Software 
El Sobrante, CA 

Dear UNIX REVIEW, 

I opened my first issue of UNIX REVIEW to discover a 
letter decrying the use of the goto statement. I will not 
argue that the goto is a crutch for inadequate 
programmers. But please, please , do not forget the 
“kludge” programmer in C. This level of programmer 
needs as many crutches as he can get to get jobs done! 

I am a “kludge” programmer. I get jobs done. My 
programs may not be sophisticated, but they do work. 
If I write a program that is going to be used frequently 
enough to warrant it. I’ll have it rewritten by a 
PROGRAMMER. (That’s all capital letters, and no 
smile!) I highly respect the type of person who has the 
discipline to write concise and efficient code. But I am 
a mechanical engineer and not a PROGRAMMER. I do 
not apologize for this fact and I highly resent it when a 
tool, such as C, is closed to me by the search for 
“purity”. 

I have been writing programs in C since January. I 
find it to be a highly useful tool. As far as I know, C and 
FORTH are the only widely available languages that 
were written by people who needed to get jobs 
done...period. The other languages were either writ¬ 
ten to teach people “good” programming style or to 
support antiquated I/O systems. I am usually the 
person dragging my (antiquated) portable 8-bit ma¬ 
chine around in order to have a FORTH system 
available to me so that my jobs will get done on time. 
This has changed considerably since January. I hope 
that this trend will continue. 

Lew Merrick 
Lynnwood, WA 
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ZIM 2.5 A DBMS REWLUTION 



Woodward Drive 
Ontario K2C 0R1 
(613) 727-1397 


ZANTHE 

INFORMATION INC 


Power 

ZIM's high-level language lets you build user commands which 
implement applications without the necessity and cost of additional 
programming tools. ZIM's forms facility and extensive report 
generator permit completely menu-driven applications. Completed 
compiled, applications use the Runtime System, leading to fast 
execution, preventing unauthorized access or modifications, and 
decreasing cost and memory requirements. 

Flexibility 

ZIM gives you unprecedented simplicity and flexibility. ZIM 
commands parallel simple English sentences, making it easy to 
learn and use. Other features include automatic updates of all 
indexes, multi-user support, and an extensive range of validation, 
editing and masking facilities. ZIM's limits are only those of your 
hardware, operating system and imagination. And with ZIM 2.5, 
your database is no longer limited to a single hard disk. 


Have you been looking for perfect data management that you can 
enjoy on your own terms? Then you've probably already heard of 
ZIM 2.4 — the most powerful database system available. Until now. 
Because ZIM 2.5 is here. 


ZIM 2.5 is a fourth generation application development tool which 
makes it possible to expand the capabilities of your micro beyond 
what you've ever imagined. ZIM mirrors the complexities of the 
real world by letting you develop as many and as varied 
applications as you could possibly need. 


"ZIM is... a successful migration of mainframe ideas and needs to a 
micro. (ZIM) proves not only that the job can be done but also that 
it can be done well. ZIM provides a reference against which current 
and future data bases can be judged. " James Creane, Data Based 
Advisor/July 1985. 


Speed 

ZIM breaks the speed limit — between 3 and 50 times faster than 
industry leaders in sorting and joining files within the data-base. 
ZIM's internal architecture, and the implementation of its strategy 
analyzer and priority-driven buffering ability, ensure that data is 
processed in the most efficient manner possible. 

Portability 

ZIM is the only database management system with 100% 
application portability for single-user and multi-user 
:onfigurations. ZIM is available under PC-DOS, 

Zoncurrent PC-DOS, UNIX, XENIX, and QNX. 

Mever again will you be required to re-write 
/our applications for different operating systems 
environments. 
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"ZIM is (a) well-conceived , soundly-implemented , 
thoroughly professional system. Its design evidences a 
strong commitment to consistency and to the goal 
of natural nonprocedural user interaction." 

Richard M. Foard, PC Tech Journal, 
October 1985. 


ZIM 2.5 — DATA 
MANAGEMENT AT 
ITS BEST 






























The Language for a New Generation 


Portability. UX-Basic™ application 
programs execute unchanged on any UNIX™ 
machine and are completely device independent. 

Power. UX-Basic contains the building 
blocks for efficient application program develop¬ 
ment. It also allows you to tap the full power of 
UNIX and gives you direct access to data bases. 

Productivity. UX-Basic is friendly and 
easy to learn and use. The interactive program¬ 
ming environment provides syntax checking as 
well as real-time debugging and testing. 


Performance. UX-Basic gives you speed 
when you need it with our efficient pseudo-code 
compiler/runtime package. We are constantly 
working to keep UX-Basic’s performance at the 
leading edge. 

Profit. UX-Basic programs are structured, 
modular and readable. Maintenance and support 
are easy. 

Perfect for UNIX ... a new generation of 
computers... a new generation of computer 
users. 


SEUniForum 

The International Conference of UNIX Users 
February 4-7,1986 


UX Software, Inc. 

10 St. Mary Street, Toronto, Canada M4Y1P9 
Tel: (416) 964-6909 TLX: 065-24099 

Available from major computer manufacturers such as Altos. AT&T, 
Siemens and an international network of distributors. 


UNIX is a trademark of AT&T Laboratories. 
UX-Basic is a registered Trademark of UX Software, Inc. 


See us at 


M'85 


November 20-24. 1985 
Las Vegas Convention Center-West Hall 
Las Vegas, Nevada 
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